bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs


From: Eli Zaretskii
Subject: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Fri, 19 Mar 2021 13:55:41 +0200

> Cc: schwab@linux-m68k.org, mwd@md5i.com, 47244@debbugs.gnu.org, mwd@cert.org
> From: martin rudalics <rudalics@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]