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

[Michael Welsh Duggan]

martin rudalics <rudalics@gmx.at> writes:

>> Surprisingly, no.  Three frames were checked.  The only buffers in
>> windows involved in the entire process were:
>>
>> "build.ninja"  - I had that file in another frame
>> " *Minibuf-0*" - Looks like this was in the same frame as build.ninja?
>> "*Server*"     - This was the window whose buffer is being deleted
>
> But *Server* _is_ the buffer that shall be killed IIUC - the obj passed
> to window_loop.  I nowhere see that you tried
>
> p XBUFFER (w->contents)->name_
>
> below.  Basically when you encounter the
>
> if (EQ (w->contents, obj))
>
> eventually w->contents should be that buffer.  And apparently
> w->contents never is that buffer.  Can you check again?

Actually, what I did is use xbuffer, which as part of it outputs the
name_.  For example:

(gdb) p w->contents
$53 = XIL(0x5555578be555)
(gdb) xbuffer
$54 = (struct buffer *) 0x5555578be550
0x555557241db0 "build.ninja"

In this case the name_ field is "build.ninja".  The definition of
xbuffer is:

define xbuffer
  xgetptr $
  print (struct buffer *) $ptr
  xgetptr $->name_
  output $ptr ? (char *) ((struct Lisp_String *) $ptr)->u.s.data : "DEAD"
  echo \n
end
document xbuffer
Set $ as a buffer pointer and the name of the buffer.
This command assumes $ is an Emacs Lisp buffer value.
end

When window_list_1() gets called with the window that has "*Server*" as
the buffer, window_list() (as called on line 2866) does not return a
list that contains that window.  I do not know how Vwindow_list (which
is what is returned by window_list() gets updated.

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