bug#60096: 29.0.60; Crash in format_mode_line_unwind_data

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 17 Dec 2022 16:26:36 +0100
> Cc: juri@linkov.net, 60096@debbugs.gnu.org
> From: martin rudalics <rudalics@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.

> 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 about the other parts of the changeset I installed -- do they
>  > look okay to you? any comments?
> 
> I see
> 
> -  return safe_call (1, Qget_scratch_buffer_create);
> +  /* This function must return a valid buffer, since it is frequently
> +     our last line of defense in the face of the expected buffers
> +     becoming dead under our feet.  safe_call below could return nil
> +     if recreating *scratch* in Lisp, which does some fancy stuff,
> +     signals an error in some weird use case.  */
> +  buf = safe_call (1, Qget_scratch_buffer_create);
> +  if (NILP (buf))
> +    {
> +      AUTO_STRING (scratch, "*scratch*");
> +      buf = Fget_buffer_create (scratch, Qnil);
> +    }
> +  return buf;
> 
> and
> 
> +      Fset_buffer_major_mode (buf);
> 
> which look okay to me.  Unless, again, the latter would try to deal with
> the window list or do some other nasty stuff.  Then other_buffer_safely
> should not be allowed to recreate *scratch* but rather some fallback
> buffer in fundamental mode with no hooks run and any buffer lists having
> it as single element.

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

Thanks.