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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: mwd <at> md5i.com, 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: Tue, 30 Mar 2021 17:48:01 +0300

> Cc: Eli Zaretskii <eliz <at> gnu.org>, "mwd <at> md5i.com" <mwd <at> md5i.com>,
>  "schwab <at> linux-m68k.org" <schwab <at> linux-m68k.org>,
>  "47244 <at> debbugs.gnu.org" <47244 <at> debbugs.gnu.org>
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 30 Mar 2021 16:36:50 +0200
> 
>  > The breakpoint I put on the error() clause added to buffer.c triggered
>  > again in the new build without touching any of the easserts.
> 
> And I thought I was overdoing with them.  This error is a bit too elusive
> for my brain.

Maybe instead of trying to find the exact culprit, we should simply
protect this code:

      /* Make sure the current window's buffer is selected.  */
      set_buffer_internal (XBUFFER (XWINDOW (selected_window)->contents));

from selecting a dead buffer?  For example, by using
other_buffer_safely if the selected-window's buffer is dead.  After
all the code in question, viz.:

      (gnus-kill-buffer (current-buffer))

is already quite crazy: who in their right mind kills the current
buffer in the middle of a Lisp program?  What were they thinking?

Previous Next

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