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

[Trevor Bentley]

> > 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