[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
From: |
Michael Welsh Duggan |
Subject: |
bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs |
Date: |
Fri, 19 Mar 2021 09:37:21 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Michael Welsh Duggan <mwd@md5i.com>
>> Cc: Andreas Schwab <schwab@linux-m68k.org>, mwd@cert.org, mwd@md5i.com,
>> 47244@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@md5i.com)
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, (continued)
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/18
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Eli Zaretskii, 2021/03/18
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/18
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Eli Zaretskii, 2021/03/18
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/18
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Eli Zaretskii, 2021/03/18
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Andreas Schwab, 2021/03/18
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Eli Zaretskii, 2021/03/18
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/18
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Eli Zaretskii, 2021/03/19
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs,
Michael Welsh Duggan <=
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/19
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Eli Zaretskii, 2021/03/19
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Eli Zaretskii, 2021/03/19
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/19
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/19
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Eli Zaretskii, 2021/03/19
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/19
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/23
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Eli Zaretskii, 2021/03/23
- bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs, Michael Welsh Duggan, 2021/03/23