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

Previous Next

Full log

Message #773 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: Sun, 13 Dec 2020 20:59:34 +0100

>> Hmm, that makes it trickier.  No clue if my default packages 
>> launch threads, but it's possible. 
> 
> Grep them for make-thread. 
> 
>> I just hit the bug in one of my sessions: the call to 
>> unblock_input() in garbage_collect() never returns. 
> 
> If that ran in a thread, perhaps the thread died. 
> 
>> But the session still completely works, so I'm not really sure 
>> what's going on here. 
> 
> As long as the main thread runs, you might indeed see nothing 
> special. 

This was exactly my thought: a thread I'm not even aware of must 
be silently crashing and leaving GC in a bad state.

But there's only a single case of 'make-thread' in my ~/.emacs.d/, 
and it's extremely unlikely that function ever runs 
("lsp-download-install").

More importantly, I'm comparing (list-threads) in emacs and "info 
threads" in gdb, and the failed instance looks identical to the 
non-failed instances: a single emacs thread ("Main"), and three 
real threads ("emacs", "gmain", "gdbus").  garbage_collect() not 
present in any backtrace when interrupted.

I'm at a loss for how it teleported out of that garbage_collect() 
call.  Back to printf, I guess.  Maybe there was a short-lived 
thread that isn't normally running...

-Trevor

Previous Next

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