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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Trevor Bentley <trevor <at> trevorbentley.com>
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: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Sun, 13 Dec 2020 17:30:42 +0200

> From: Trevor Bentley <trevor <at> trevorbentley.com>
> Cc: monnier <at> iro.umontreal.ca, carlos <at> redhat.com, fweimer <at> redhat.com,
>  43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com
> Cc: 
> Date: Sun, 13 Dec 2020 11:20:32 +0100
> 
> 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 you use packages or commands that create Lisp threads, I think GC
can run from any of these Lisp threads.

Previous Next

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