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

[Eli Zaretskii]

> From: Michael Welsh Duggan <mwd@cert.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, "mwd@md5i.com" <mwd@md5i.com>,
>         "schwab@linux-m68k.org" <schwab@linux-m68k.org>,
>         "47244@debbugs.gnu.org"
>  <47244@debbugs.gnu.org>
> Date: Wed, 31 Mar 2021 09:53:56 -0400
> 
> And, trapped!  Backtrace is included.  Maybe unfortunately, it isn't one
> of the new easserts, but at least we now have a different backtrace.
> Hopefully that will lead to new insights.  I will note that, in this
> instance, the reproducer did not follow the same formula, as you can see
> in the Lisp backtrace.
> 
> #0  raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
>         set = {
>           __val = {402653184, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 268435456, 0, 0, 
> 93824994300624, 18446744067266838271}
>         }
>         pid = <optimized out>
>         tid = <optimized out>
> #1  0x00005555557197a1 in terminate_due_to_signal
>     (sig=6, backtrace_limit=2147483647) at ../../master/src/emacs.c:416
> #2  0x00005555557c4858 in die
>     (msg=0x55555594f2a0 "b->window_count == 0", file=0x55555594da8a 
> "../../master/src/buffer.c", line=1969) at ../../master/src/alloc.c:7420
> #3  0x0000555555759190 in Fkill_buffer (buffer_or_name=XIL(0x555557888814))
>     at ../../master/src/buffer.c:1969
>         buffer = XIL(0x555557889325)
>         b = 0x555557889320
>         tem = XIL(0)
>         m = 0x0

So replace_buffer_in_windows didn't do its job?

Unfortunately, this assertion is _after_ we make the buffer's name
nil, so no way of knowing for sure which buffer is that, except by
looking at the Lisp which triggered that.