From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: enometh@meer.net, 39977@debbugs.gnu.org
Subject: bug#39977: 28.0.50; Unhelpful stack trace
Date: Sat, 28 Mar 2020 11:23:29 +0300 [thread overview]
Message-ID: <83y2rk7uri.fsf@gnu.org> (raw)
In-Reply-To: <c8db7b61-71f8-3f96-2f62-497720431d09@gmx.at> (message from martin rudalics on Tue, 24 Mar 2020 10:45:16 +0100)
> Cc: enometh@meer.net, 39977@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 24 Mar 2020 10:45:16 +0100
>
> >> (and (frame-live-p (selected-frame))
> >> (window-live-p (selected-window))
> >> (eq (frame-selected-window (selected-frame))
> >> (selected-window)))
> >
> > I agree. But note that selected-frame could switch frames internally,
> > if the last selected frame is dead; as long as selected-frame also
> > adjusts the selected window, the above will still hold.
>
> Do you mean 'select-frame' instead of 'selected-frame'?
No, I meant selected-frame.
> > I'm okay with having non-deterministic behavior triggered by code that
> > violates that invariant. We will tell people who write such Lisp code
> > "if it hurts, don't do that".
>
> But till then we may have to handle reports of bugs that are very hard
> to reproduce.
Bugs that are caused by such invalid Lisp, and that manifest
themselves by unexpected or unpredictable behavior, are fine with me.
Of course, it would be good to find the causes of such bugs and point
them out to the responsible Lisp programmer, but as long as we don't
crash or lock up, we are in a relatively good shape.
> >> Wrong type argument: window-live-p, #<window 3>
> >>
> >> error in redisplay.
> >
> > That might not be the best solution, but it's "good enough" in my
> > book. The programmer who writes such code deserves punishment, and an
> > error in redisplay that doesn't lock up Emacs (or does it?) is ample
> > punishment, IMO.
>
> This error might be due to the fact that _any_ of old_top_frame,
> old_window and target_frame_window in unwind_format_mode_line can be
> dead at the time of unwinding. unwind_format_mode_line is much to
> fragile in this regard.
Perhaps we should make unwind_format_mode_line less fragile, then.
> And I have no idea yet why we need an extra unwind for restoring
> selected_frame and selected_window. Shouldn't these go hand in hand
> with what unwind_format_mode_line does? Does the one even know
> about the other?
I don't think I understand what extra unwind are you talking about
here. Can you provide a more specific pointer to the relevant code?
next prev parent reply other threads:[~2020-03-28 8:23 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-07 17:43 bug#39977: 28.0.50; Unhelpful stack trace Madhu
2020-03-07 18:50 ` Eli Zaretskii
2020-03-13 9:55 ` Eli Zaretskii
2020-03-13 16:28 ` martin rudalics
2020-03-13 19:43 ` Eli Zaretskii
2020-03-14 8:48 ` martin rudalics
2020-03-14 10:10 ` Eli Zaretskii
2020-03-14 10:37 ` martin rudalics
2020-03-14 18:55 ` martin rudalics
2020-03-14 20:09 ` Eli Zaretskii
2020-03-15 17:49 ` martin rudalics
2020-03-15 18:41 ` Eli Zaretskii
2020-03-16 9:24 ` martin rudalics
2020-03-16 15:33 ` Eli Zaretskii
2020-03-17 9:38 ` martin rudalics
2020-03-17 15:51 ` Eli Zaretskii
2020-03-17 17:31 ` martin rudalics
2020-03-17 17:45 ` Eli Zaretskii
2020-03-17 18:39 ` martin rudalics
2020-03-17 19:41 ` Eli Zaretskii
2020-03-18 9:12 ` martin rudalics
2020-03-18 14:53 ` Eli Zaretskii
2020-03-18 18:48 ` martin rudalics
2020-03-18 19:36 ` Eli Zaretskii
2020-03-19 8:55 ` martin rudalics
2020-03-19 14:33 ` Eli Zaretskii
2020-03-21 9:32 ` martin rudalics
2020-03-21 13:15 ` Eli Zaretskii
2020-03-22 18:20 ` martin rudalics
2020-03-23 14:48 ` Eli Zaretskii
2020-03-24 9:45 ` martin rudalics
2020-03-28 8:23 ` Eli Zaretskii [this message]
2020-03-28 18:38 ` martin rudalics
2020-04-03 16:32 ` martin rudalics
2020-04-10 11:51 ` Madhu
2020-09-30 15:06 ` Lars Ingebrigtsen
2020-09-30 15:31 ` Eli Zaretskii
2020-09-30 17:29 ` martin rudalics
2020-10-01 0:01 ` Lars Ingebrigtsen
2020-10-01 4:37 ` Madhu
2020-03-19 3:48 ` Madhu
2020-03-16 2:42 ` Madhu
2020-03-16 9:25 ` martin rudalics
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=83y2rk7uri.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=39977@debbugs.gnu.org \
--cc=enometh@meer.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).