unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 60096@debbugs.gnu.org, juri@linkov.net
Subject: bug#60096: 29.0.60; Crash in format_mode_line_unwind_data
Date: Sat, 17 Dec 2022 19:52:12 +0200	[thread overview]
Message-ID: <83edsxhq9f.fsf@gnu.org> (raw)
In-Reply-To: <89b63947-5b2d-8bd1-4e9a-7da6cf114ffe@gmx.at> (message from martin rudalics on Sat, 17 Dec 2022 18:05:58 +0100)

> Date: Sat, 17 Dec 2022 18:05:58 +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.
> 
> 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.





  reply	other threads:[~2022-12-17 17:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-15 17:04 bug#60096: 29.0.60; Crash in format_mode_line_unwind_data Juri Linkov
2022-12-15 21:42 ` Eli Zaretskii
2022-12-16  7:31   ` Juri Linkov
2022-12-16 11:46     ` Eli Zaretskii
2022-12-16 14:39       ` Eli Zaretskii
2022-12-16 15:03         ` Eli Zaretskii
2022-12-17  9:17           ` martin rudalics
2022-12-17 10:00             ` Eli Zaretskii
2022-12-17 10:53               ` Eli Zaretskii
2022-12-17 15:26               ` martin rudalics
2022-12-17 15:59                 ` Eli Zaretskii
2022-12-17 17:05                   ` martin rudalics
2022-12-17 17:52                     ` Eli Zaretskii [this message]
2022-12-18  9:18                       ` martin rudalics
2022-12-18 11:40                         ` Eli Zaretskii
2022-12-17 17:23           ` Juri Linkov
2022-12-17 17:59             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83edsxhq9f.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=60096@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).