bug#55371: 29.0.50; lock-up in redisplay_internal

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

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

It was not looping.  It was stuck in the poll call in frame 0.

-- 
Michael Welsh Duggan
(md5i@md5i.com)