From: Michael Welsh Duggan <mwd@md5i.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Michael Welsh Duggan <mwd@md5i.com>, 55371@debbugs.gnu.org
Subject: bug#55371: 29.0.50; lock-up in redisplay_internal
Date: Wed, 11 May 2022 13:04:38 -0400 [thread overview]
Message-ID: <87ilqcngpl.fsf@md5i.com> (raw)
In-Reply-To: <83ilqcqcfi.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 11 May 2022 19:08:49 +0300")
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)
next prev parent reply other threads:[~2022-05-11 17:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-11 15:08 bug#55371: 29.0.50; lock-up in redisplay_internal Michael Welsh Duggan
2022-05-11 16:08 ` Eli Zaretskii
2022-05-11 17:04 ` Michael Welsh Duggan [this message]
2022-05-11 17:15 ` Eli Zaretskii
2022-05-11 17:16 ` Michael Welsh Duggan
2022-05-12 0:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-12 22:09 ` Michael Welsh Duggan
2022-07-05 11:36 ` Lars Ingebrigtsen
2022-07-05 23:57 ` Michael Welsh Duggan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ilqcngpl.fsf@md5i.com \
--to=mwd@md5i.com \
--cc=55371@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.