bug#55371: 29.0.50; lock-up in redisplay_internal

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Welsh Duggan <mwd@md5i.com>
> Date: Wed, 11 May 2022 11:08:11 -0400
> 
> I wrote a dbus event watcher that triggers when my network connection
> changes (for me, this is usually because I am switching to or from a
> VPN).  As part of this, I call `gnus-close-all-servers` (this allows
> gnus to reconnect to servers from its new network state).  In this
> particular instance, this led to a chain of events that
> redisplay_internal being called, from which Emacs became unresponsive.
> As I was running Emacs from a debugger (to potentially debug a different
> problem), I was able to send a TSTP signal, get a backtrace, and then
> used "return -1" "c" to get back in a state where I could hit C-g a
> couple of times and regain interactivity.
> 
> This was a random event that may be already solved in a later version,
> and it may or may not be reproducible in the future, but I wanted to
> send the backtrace now while I had one in case any part of it was
> actually informative.

Thanks.  However, to debug such lockups, we need to know where was the
code looping.  And from the backtrace and your description, I cannot
figure that out.  Did you try the technique described in etc/DEBUG
under "If the symptom of the bug is that Emacs fails to respond", and
if so, can you tell which code was looping, never returning to its
caller?

> Backtrace follows Emacs info.

The backtrace tells me that Emacs was inside some Xlib function,
perhaps related to an input method or something?  That doesn't let us
enough rope to try unlocking this.