Jerry James <james(a)xemacs.org> writes:
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
>>>>>>"JJ" == Jerry James <Jerry.James(a)usu.edu> writes:
> JJ> Fatal error: assertion failed, file
> JJ> /home/james/xemacs/xemacs-21.5/src/alloc.c, line 398,
> JJ> !regex_malloc_disallowed
>
> If you've enabled the new garbage collector, this seems to be a
> problem I've introduced. I've received another bug report about
> regex_malloc_disallowed, and got bitten by this bug myself once. If
> you have a --disable-newgc build, I am more than happy because then
> this bug isn't a NEWGC problem, but I doubt it. Anyway, I am going to
> look into this the next days.
Yes, I have newgc turned on. I am also happy to report that this bug is
very easy to trigger with Gnus. So easy to trigger, in fact, that I've
given up using Gnus with XEmacs 21.5 for the time being.
This, presumably, depends on your configuration. I have almost no
problems with Gnus and XEmacs 21.5 (full debug and error checking)
running, so it isn't quite that simple, thankfully.
NEWGC does run very well for me, and the asynchronous finalization code
means that my previous fix to the image GC code is no longer need, which
is lovely.
I have run into one issue, thus far, which is that a long running XEmacs
worked slowly up to 608MB of allocated memory before it stopped being
able to fork and I restarted it.[1]
On that topic, what is the best way to track down a memory leak with the
NEWGC code? Is there anything specific that I can look at to help work
out what the leak is and why it is happening?
Daniel
Footnotes:
[1] Foolishly, I didn't actually bother to grab a core or any memory
use information, so I am currently working back up toward that.
--
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707 email: contact(a)digital-infrastructure.com.au