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

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Mon, 29 Mar 2021 18:05:35 +0200

> Martin, could it be that replace-buffer-in-windows fails to replace a
> buffer?  Suppose kill-buffer is called to kill a buffer that is shown
> in the selected window, but replace-buffer-in-windows fails to replace
> it -- can that happen?

That's what we tried earlier with the check in `switch-to-prev-buffer'.
Michael did you run with that check this time or did you remove it?  If
the latter, please reinsert it for the next time.  But let's recall that
at the time of the last segfault that particular check did not trigger.

> And another question: can a window be selected if its buffer is dead?
> Or is it possible to set a dead buffer as a window's buffer?

From what we can say now one of these must have happened.  The dead
buffer comes from the selected window.  It does not come from the
attempt to restore the current buffer from a temporarily saved one.

One thing I'm not even sure about is whether the selected window is
still "live" when were trying to make its buffer current.  Michael is
this "window" supposed to be the only one on its frame?  Are we sure
that it is not the minibuffer window?  In either case we could try to
investigate its parent and geometry: What do

p XWINDOW (selected_window)->parent
p XWINDOW (selected_window)->prev
p XWINDOW (selected_window)->next
p XWINDOW (selected_window)->top_line
p XWINDOW (selected_window)->pixel_height

print?

Thanks, martin

Previous Next

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