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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
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 18:05:58 +0100

>> 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.

>> 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'?

> 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.

martin

Previous Next

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