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

[Michael Welsh Duggan <mwd@cert.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Welsh Duggan <mwd@cert.org>
>> Date: Thu, 08 Apr 2021 12:01:23 -0400
>> Cc: Michael Welsh Duggan <mwd@md5i.com>,
>>  "schwab@linux-m68k.org" <schwab@linux-m68k.org>,
>>  "47244@debbugs.gnu.org" <47244@debbugs.gnu.org>
>> 
>> Lisp Backtrace:
>> "window-list-1" (0xffffbfa0)
>> "replace-buffer-in-windows" (0xffffc4a8)
>> "kill-buffer" (0xffffc710)
>> 0x571d80f8 PVEC_COMPILED
>> "substitute-command-keys" (0xffffd3d8)
>> "command-error-default-function" (0xffffd628)
>> "apply" (0xffffd7e8)
>> 0xf2c1d0e8 PVEC_COMPILED
>
> This seems to indicate that kill-buffer is called by
> substitute-command-keys, in which case the buffer in question is a
> temporary buffer.  Can you verify that by looking at the buffer's name
> in frame #13:
>
>> #13 0x0000555555758e6d in Fkill_buffer
>> (buffer_or_name=XIL(0x5555571d7ced)) at
>> ../../master/src/buffer.c:1830
>>         buffer = XIL(0x5555571d7ced)
>>         b = 0x5555571d7ce8
>>         tem = XIL(0x555555753673)
>>         m = 0x7fffffffc5f0

I'm afraid I cancelled that gdb session in favor of a new one recently,
sorry.  I'll report on that at the next trigger.

> And if I'm right, it sounds like we are looking at a different
> scenario here?  The previous calls to kill-buffer were from Gnus,
> right?

The scenario is the same, but recent changes my Martin have moved the
failure closer to the trigger condition.  Before I typed C-g C-g,
switched to the server buffer, changed some connections, and then things
died when the server buffer was killed.  We have managed to determine
that this is due to Vwindow_list being inconsistent with reality, and
Martin's changes have caused us to fail closer to the actual cause of
failure.

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