bug#39977: 28.0.50; Unhelpful stack trace

[martin rudalics]

>> (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