GNU bug report logs - #47244
28.0.50; SIGSEGV in long-runnning Emacs

Previous Next

Full log

View this message in rfc822 format

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>, 47244 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, mwd <at> cert.org
Subject: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Fri, 19 Mar 2021 09:37:21 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Welsh Duggan <mwd <at> md5i.com>
>> Cc: Andreas Schwab <schwab <at> linux-m68k.org>,  mwd <at> cert.org,  mwd <at> md5i.com,
>>   47244 <at> debbugs.gnu.org
>> 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. 

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.