bug#43389: 28.0.50; Emacs memory leaks using hard disk all time

[Eli Zaretskii]

> From: Trevor Bentley <trevor@trevorbentley.com>
> Cc: michael_heerdegen@web.de, monnier@iro.umontreal.ca, carlos@redhat.com,
>  fweimer@redhat.com, 43389@debbugs.gnu.org, bugs@gnu.support, dj@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?