bug#39977: 28.0.50; Unhelpful stack trace

[martin rudalics <rudalics@gmx.at>]

 >> (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'?  If so, please
note that the problems occur due to the fact that we set selected_frame
and selected_window directly without going through do_switch_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.  In the case at hand the mode-line code runs a function
'sly-db-exit' (https://github.com/joaotavora/sly/blob/master/sly.el)
where practically every single function call can have unpredictable
consequences.  And 'sly-db-exit' might be one of the milder examples of
what code can possibly do there.

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

martin