[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#60096: 29.0.60; Crash in format_mode_line_unwind_data
From: |
Eli Zaretskii |
Subject: |
bug#60096: 29.0.60; Crash in format_mode_line_unwind_data |
Date: |
Sat, 17 Dec 2022 17:59:36 +0200 |
> 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.
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Juri Linkov, 2022/12/15
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Eli Zaretskii, 2022/12/15
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Juri Linkov, 2022/12/16
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Eli Zaretskii, 2022/12/16
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Eli Zaretskii, 2022/12/16
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Eli Zaretskii, 2022/12/16
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, martin rudalics, 2022/12/17
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Eli Zaretskii, 2022/12/17
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Eli Zaretskii, 2022/12/17
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, martin rudalics, 2022/12/17
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data,
Eli Zaretskii <=
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, martin rudalics, 2022/12/17
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Eli Zaretskii, 2022/12/17
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, martin rudalics, 2022/12/18
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Eli Zaretskii, 2022/12/18
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Juri Linkov, 2022/12/17
- bug#60096: 29.0.60; Crash in format_mode_line_unwind_data, Eli Zaretskii, 2022/12/17