bug#39977: 28.0.50; Unhelpful stack trace

[Eli Zaretskii <eliz@gnu.org>]

> Cc: enometh@meer.net, 39977@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 16 Mar 2020 10:24:14 +0100
> 
>  >> As far as xdisp.c is concerned it simply must not set selected_frame
>  >> to a dead frame.
>  >
>  > I don't think that's possible in xdisp.c cases you've shown.
>  >
>  >> Never ever.
>  >
>  > Why not?
> 
> Because it might shift the abort to the next instance of SELECTED_FRAME.

Why does it matter which SELECTED_FRAME crashes?

Anyway, my point was a different one: it was that we cannot simply
"not select" such a frame, we need to do something else.  What exactly
is not trivial, and I didn't understand what you were suggesting to
do.

>  >> As far as frame.c is concerned, it should do something like in the
>  >> attached patch.
>  >
>  > We cannot punt like that in the display engine.
> 
> Why not?

Because we must have a frame that we were supposed to redisplay.

> At least one of the frame restorations is unprotected anyway
> and might leave the temporarily selected frame selected.

The display engine doesn't select frames to show them to the user, it
selects them to redraw their windows.  So the considerations what to
do in this case are different from those we need to consider when the
user selects a frame.

>  > So you are saying that selecting such a frame will cause trouble to
>  > some other code, not to the display engine?
> 
> Not "will" but "may".  The problem is that it then might be harder
> to find the cause.
> 
> With emacs -Q evaluate
> 
> (defvar foo
>    '(:eval
>      (when (> (length (frame-list)) 1)
>        (delete-frame (next-frame)))))
> 
> (setq-default mode-line-format foo)
> 
> and do C-x 5 2.  The backtrace I get here is

Which just means we need to add the protection to SELECTED_FRAME
itself, so that it runs everywhere.