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

Previous Next

Full log

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

From: Trevor Bentley <trevor <at> trevorbentley.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com,
 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: Sun, 13 Dec 2020 11:20:32 +0100

>> Dunno if it matters, but `gnus-registry-save' binds it 
>> temporarily to a high value 
> 
> I'd prefer very much that our core code never did that. 

I'm not sure what that is, but I'm not calling it directly, and 
probably not indirectly either.  Not doing any mail reading in the 
instances that are inflating.

I print the gc variables in each of my log analyses, and they have 
always been the same: the default.

I have one instance running that has clearly hit the problem. 
garbage_collect() never printed its "end" message, and there have 
been no further garbage collects in nearly 20 hours:

----
1607783297: garbage_collect start 1607783297: gc_sweep start 
1607783297: gc_sweep end (0 s) ----

Right now, I'm leaning towards this being the root cause. 
Something is causing a garbage collect to crash or hang or 
otherwise exit in some unknown way, and automatic garbage 
collection gets disabled until I manually retrigger it.

Garbage collect never runs on other threads/forks, right?  If it 
were hung forever inside garbage_collect(), I would expect the 
whole window to be frozen, but it is not.

I'll add more printfs in garbage_collect() and try to figure out 
where it is exiting.

-Trevor

Previous Next

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