GNU bug report logs - #60096
29.0.60; Crash in format_mode_line_unwind_data

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 60096 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60096: 29.0.60; Crash in format_mode_line_unwind_data
Date: Sat, 17 Dec 2022 19:52:12 +0200

> Date: Sat, 17 Dec 2022 18:05:58 +0100
> Cc: juri <at> linkov.net, 60096 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  >> Alternatively, we could exclude windows with a nil buffer in
>  >> add_window_to_list (think of the case that within the blurb
>  >> producing code someone wants to consult the window list).
>  >
>  > Maybe we should try this on master.  I indeed expected
>  > add_window_to_list to filter such invalid windows and was surprised
>  > that it didn't.  Basically, I don't understand how we never had such
>  > windows in the list before, since there's no code which actively
>  > removes them and thus protects the list from holding such windows.  I
>  > think we just have been lucky.
> 
> Probably so far we never tried to call 'kill-buffer' from within
> 'set-window-configuration'.  If the only "live" window shows *scratch*,
> *scratch* gets killed and we kill a temporary buffer before we were able
> to recreate *scratch*, window_list will return the empty list.

Why the empty list?  The buffer gets killed, but windows don't get
killed.  We still have the frame with at least two windows (including
the mini-window).  Right?

>  >> Principally, we should never run 'replace-buffer-in-windows' from within
>  >> 'set-window-configuration'.
>  >
>  > This can no longer be guaranteed, given that other_buffer_safely calls
>  > into Lisp, and so do a few other primitives.
> 
> What if such a call into Lisp tries to run 'set-window-configuration'?

Indeed.  Maybe we should protect set-window-configuration from being
re-entered?

>  > You are right in principle, but other_buffer_safely was doing the
>  > above for many years before we acquired get-scratch-buffer-create and
>  > started calling it from here.  So I think we are relatively safe
>  > (again, maybe by pure chance).
> 
> Then not calling 'get-scratch-buffer-create' from other_window_safely
> would be more safe.

You mean, return to what we did before get-scratch-buffer-create was
invented?  It's possible.

Previous Next

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