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

[Michael Welsh Duggan]

martin rudalics <rudalics@gmx.at> writes:

>  >> The mysterious aspect is (2): Why did window_list skip the *Server*
>  >> window?
>  >
>  > Good question.  I plan to set Vwindow_list to nil and call it to see
>  > what happens.
>
> This should resolve the mystery.

I wish it did.  After doing this, Vwindow_list has six entries, one for
each selected_window on each frame, and one for each minibuffer window
on each frame.  This includes the "*Server*" buffer.

>  >> What is the value of FRAME_ROOT_WINDOW (f) where f is the
>  >> *Server* frame?  What is the name of that window's buffer?
>  >
>  > It's a window containing the buffer "*Server*".
>
> So a bad FRAME_ROOT_WINDOW can't be the cause for (2).
>
>  >> IIUC the *Server* frame does not have a minibuffer window - correct?
>  >
>  > It didn't appear in Vwindow_list, but it does have a minibuffer.
>  >
>  > (gdb) p $116->minibuffer_window
>  > $139 = XIL(0x555556fc8185)
>  > (gdb) xwindow
>  > $140 = (struct window *) 0x555556fc8180
>  > 84x1+0+59
>  > (gdb) p $140->contents
>  > $141 = XIL(0x7ffff2a3cb15)
>  > (gdb) xbuffer
>  > $142 = (struct buffer *) 0x7ffff2a3cb10
>  > 0x7ffff2d244ea " *Minibuf-0*"
>  >
>  > I will note that the window itself is different than the one on the
>  > Vwindow_list with the same contents.
>
> Are you sure it's on the same frame as the *Server* window (w->frame
> gives you that)?  What is the value of w->next for the *Server* window?

I am certain.  w->next on that window is a minibuffer window.

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