Re: 21.5 crash in Gnus

DP> This, presumably, depends on your configuration. I have almost no DP> problems with Gnus and XEmacs 21.5 (full debug and error checking) DP> running, so it isn't quite that simple, thankfully. Same here. I hit this bug once and am failing since then to reproduce it. Jerry, can you please post your Installation file? DP> NEWGC does run very well for me, and the asynchronous finalization code DP> means that my previous fix to the image GC code is no longer need, which DP> is lovely. Do you mean this? Subject: [PATCH] [RECOMMEND 21.4] Stopping timeouts during GC causes lossage on all GUI platforms (X11, GTK and Win32) DP> I have run into one issue, thus far, which is that a long running XEmacs DP> worked slowly up to 608MB of allocated memory before it stopped being DP> able to fork and I restarted it.[1] DP> On that topic, what is the best way to track down a memory leak with the DP> NEWGC code? Is there anything specific that I can look at to help work DP> out what the leak is and why it is happening? The only thing is to keep an eye on show-object-memory-usage-stats and show-mc-alloc-memory-usage and see which objects escape. It might also be a fragmentation problem of the allocator. Valgrind might be useful, but there are issues with NEWGC's write barrier: The virtual dirty bit write barrier provokes SEGFAULTs on purpose to keep track of object modifications. Valgrind reports all of these SEGFAULTs, which makes it is practically useless. But valgrind is able to ignore certain bugs, defined by a set of rules, called supressions. Maybe this way valgrind can be tweaked to work with the write barrier. Before I start on this: Is somebody here familiar with valgrind supressions? -- Marcus