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 22:21:00 +0200

> From: Trevor Bentley <trevor <at> trevorbentley.com>
> Cc: michael_heerdegen <at> web.de, 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 20:59:34 +0100
> 
> > 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...

Does thread-last-error return something non-nil?

Previous Next

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