GNU bug report logs - #43389
28.0.50; Emacs memory leaks

Previous Next

Full log

Message #785 received at 43389 <at> debbugs.gnu.org (full text, mbox):

From: Trevor Bentley <trevor <at> trevorbentley.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, dj <at> redhat.com, bugs <at> gnu.support,
 michael_heerdegen <at> web.de, carlos <at> redhat.com, monnier <at> iro.umontreal.ca, 
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Mon, 14 Dec 2020 22:24:56 +0100

>> > Does thread-last-error return something non-nil?  
>>  Nope, nil in all instance, including the one in a weird state. 
> 
> Then it's unlikely that a thread died unnatural death. 
> 

No, sure doesn't seem like it.  Just hit it in an instance with 
more printfs, and it looks like it leaps right out of some 
sub-call of process_pending_signals(), continuing to run elsewhere 
without finishing garbage_collect().  To me, that means exactly 
one thing: longjmp.

If something manages to longjmp out of garbage_collect() at that 
point, it leaves with consing_until_gc set to HI_THRESHOLD.  This 
must explain why automatic GC stops running for hours or days, but 
manual GCs still work.

I tried setting a breakpoint in longjmp, but it's called 3 times 
for every keypress!  That's inconvenient.  Running one single 
instance now with a conditional breakpoint on longjmp: it will 
break if longjmp is called while it's in unblock_input().

-Trevor

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.