bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Welsh Duggan <mwd@cert.org>
>> Cc: Michael Welsh Duggan <mwd@md5i.com>,
>>         "47244@debbugs.gnu.org"
>>  <47244@debbugs.gnu.org>
>> Date: Thu, 18 Mar 2021 12:54:20 -0400
>> 
>> (gdb) p current_buffer->name_
>> $8 = XIL(0)
>> (gdb) xstring
>> $9 = (struct Lisp_String *) 0x0
>> "DEAD"
>
> So a buffer that was killed somehow became the current buffer, or the
> selected buffer in some window.  I have no idea how that could happen.
> At this point, all I can suggest is to try making redisplay simply
> return when faced with such buffers, which is really just a band-aid.
>
> Can you tell more about this "resetting" of Gnus, and what it means to
> "switch VPN on/off"?

Sure.  To connect to work I have to start the VPN, which changes my
network routing.  When Gnus tries to fetch new messages over an existing
IMAP connection (pre-VPN), it hangs.  I `C-g' out of it, go to the
server buffer (`^`), close the IMAP connection and then re-open it (`C
O`).  The crash happened when I hit `q` in the server buffer to get back
to the Group buffer.  This has happened several times, but the crash
doesn't happen every time.  I don't know that the VPN has anything to do
with this; it might simply provide the impetus that leads to the
problematic situation.

I do have a gnus demon running in the background:
  (gnus-demon-add-handler 'gnus-demon-scan-news 5 nil)

I don't know is this timer triggering at just the wrong time might
contribute to this.

If you want me to set a conditional breakpoint anywhere I can do that in
hopes of capturing something more useful the next time this happens.

-- 
Michael Welsh Duggan
(mwd@cert.org)