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

[Michael Welsh Duggan]

martin rudalics <rudalics@gmx.at> writes:

>> Triggered.  Here's the backtrace:
>>
>> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647)
>>      at ../../master/src/emacs.c:379
>> #1  0x00005555557c4aa2 in die
>>      (msg=0x5555559105c8 "window_list_length == list_length
>> (Vwindow_list)", file=0x55555590f9cf "../../master/src/window.c",
>> line=2585)
>>      at ../../master/src/alloc.c:7420
>>
> [...]
>> Lisp Backtrace:
>> "window-list-1" (0xffffbfa0)
>> "replace-buffer-in-windows" (0xffffc4a8)
>> "kill-buffer" (0xffffc710)
>> 0x57821b48 PVEC_COMPILED
>> "substitute-command-keys" (0xffffd3d8)
>> "command-error-default-function" (0xffffd628)
>> "apply" (0xffffd7e8)
>> 0xf2c1d0c8 PVEC_COMPILED
>
> All we can conclude from that is that Vwindow_list must have been
> clobbered before `kill-buffer' triggered the execution of
> `replace-buffer-in-windows'.  When and how that happened is yet unclear.
>
> The attached should cure the crashes by simply reconstructing the full
> list after window_list notices that Vwindow_list has changed length.

Sure.  But won't that just make it so that I can't trigger the problem
anymore?  Or is that what I am testing?

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