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

[Michael Welsh Duggan]

Michael Welsh Duggan <mwd@md5i.com> writes:

> Michael Welsh Duggan <mwd@cert.org> writes:
>
>> martin rudalics <rudalics@gmx.at> writes:
>>
>>>  > FWIW, I've been trying to do the same and have been similarly
>>>  > unsuccessful.
>>>
>>> I attach a version where I make a shadow copy of Vwindow_list called
>>> Vwindow_list_2.  The two should behave the same just that Vwindow_list_2
>>> is never accessed by other code.  So we can put an assertion like
>>>
>>>      eassert (!NILP (Fequal (Vwindow_list, Vwindow_list_2)));
>>>
>>> anywhere in the code.  I put one in window_list and it should trigger
>>> the same way as the length check before.
>>>
>>> Now if anyone can suggest some strategic positions where to put these
>>> assertions, I'll be all ears.
>>
>> I've yet to run this code yet (will do so shortly), but I'd like to
>> mention that some other debugging I've been doing involving tricky
>> breakpoint commands is implying that, somehow, list_windows() is getting
>> called while list_windows() is still running.  I've got a breakpoint
>> at the beginning of the if clause in window_list() and one at the end,
>> and it looks like I'm seeing the first one get called twice without the
>> second getting called inbetween.
>
> Okay, close, but not quite.  What seems to be happening is this:
> list_windows() is called while Vwindow_list is nil, and the if branch is
> taken.  Something causes list_windows() to exit without reaching the end
> of the if block.  This leaves Vwindow_list partially created.  The next
> time list_windows() is called it returns the partially created list.
>
> To determine this I put a breakpoint at the beginning of the if block
> that sets a gdb convenience variable called $in_list_windows to one and
> continues.  I put a breakpoint at the end of that block that sets it to
> zero and continues.  I put a third condition breakpoint at the entrance
> to list_windows() that only triggers if $in_list_windows is one.  This
> triggered with the included backtrace.
>
> Once again, the state triggered when, due to the VPN state changing, a
> background gnus demon hung trying to fetch mail.  The trigger was me
> hitting C-g twice rapidly in succession to regain interactivity.
>
> Can anyone recommend a means to check if this my theory is true?  Does
> list_windows() need to be protected against quit?

For the backtrace of that run, please note that I was using my own
modified version of list_windows(), not Martin's latest one.  I'm now
running with Martin's version for the next trigger.

-- 
Michael Welsh Duggan
(md5i@md5i.com)