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

Previous Next

Full log

View this message in rfc822 format

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: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Fri, 19 Mar 2021 13:55:41 +0200

> Cc: schwab <at> linux-m68k.org, mwd <at> md5i.com, 47244 <at> debbugs.gnu.org, mwd <at> cert.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 19 Mar 2021 10:18:33 +0100
> 
>  > Sorry, I don't understand: when kill-buffer kills the current buffer,
>  > it replaces it with another one.  Are you saying we have a way of
>  > killing buffers that bypasses kill-buffer? if so, can you describe how
>  > that can be done?
>  >
>  > Or what else am I missing?
> 
> Redisplay occasionally does things like
> 
> 	      saved_current_buffer = current_buffer;
> 	      current_buffer = XBUFFER (w->contents);
> 	      ...
>   	      current_buffer = saved_current_buffer;

It does? where?  We are talking about redisplay_internal here (because
that's where the segfault happened), not about redisplay_window and
its subroutines.  redisplay_internal generally doesn't need to be
bothered with the current buffer, it only does so once, in the
optimization it implements.  And in that code, I see no paradigm like
what you show.  Am I missing something?

> What if ... killed saved_current_buffer?

I don't see how that could happen in redisplay_internal.

Maybe you had redisplay_window in mind.  It does

  set_buffer_internal_1 (XBUFFER (w->contents));

If you imply that a window's buffer could be killed (which I still
don't understand how can happen, given what kill-buffer does), then I
think set_buffer_internal_1 would detect that.  If not, we could test
that explicitly, but then the question would be: what to do if we
detect that the buffer is indeed killed?

Previous Next

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