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

From: Michael Welsh Duggan <[email-masked]>
Date: Fri, 19 Mar 2021 09:41:47 -0400

Michael Welsh Duggan <[email-masked]> writes:

> Eli Zaretskii <[email-masked]> writes:
>
>>> From: Michael Welsh Duggan <[email-masked]>
>>> Cc: Andreas Schwab <[email-masked]>,  [email-masked],  [email-masked],
>>>   [email-masked]
>>> Date: Thu, 18 Mar 2021 21:50:28 -0400
>>> 
>>> >> Perhaps during run_window_change_functions.
>>> >
>>> > Something like that, yes.  But I don't understand how that can happen
>>> > technically: kill-buffer selects another buffer when killing the
>>> > current one.  So how was that buffer killed, and yet stayed current?
>>> 
>>> Hmm...  Is there a set of printfs we could add that would provide useful
>>> information for the next time I trigger the crash?
>>
>> I'm open to ideas.  The problem is, killing buffers is so common in
>> Emacs (including the temporary buffers you never even suspect are
>> being used under the hood) that if you put a breakpoint there, even
>> with some sophisticated condition that I don't yet know how to
>> formulate, I'm afraid that will slow down Emacs so much you will be
>> unable to work.
>>
>> But maybe my fears are exaggerated.  If you set a breakpoint on
>> Fkill_buffer with commands that say just
>>
>>   silent
>>   continue
>>   end
>>
>> does Emacs run reasonably fast for you to be able to work in such a
>> session?
>
> I just tested this.  It runs fast enough even without silent.  (I did
> this to make sure I had set up the breakpoint correctly and it was being
> triggered. 

Also, if you let me know what you would like in the breakpoint
command(s), let me know if I should first update to current master.

-- 
Michael Welsh Duggan
([email-masked])