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

Previous Next

Full log

Message #53 received at 47244 <at> debbugs.gnu.org (full text, mbox):

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

> 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?

Previous Next

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