GNU bug report logs - #39977
28.0.50; Unhelpful stack trace

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: enometh <at> meer.net, 39977 <at> debbugs.gnu.org
Subject: Re: bug#39977: 28.0.50; Unhelpful stack trace
Date: Sat, 28 Mar 2020 11:23:29 +0300

> Cc: enometh <at> meer.net, 39977 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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?

Previous Next

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