bug#39977: 28.0.50; Unhelpful stack trace

[martin rudalics]

>> Not really.  It's easy for delete_frame to refuse deleting a frame right
>> at the beginning.  But once it has accepted a deletion, it might become
>> hard to deal with all the consequences.
>
> I don't think I understand where you are going with this.

Once an initial frame has been created, Lisp code should be always able
to rely on the truth of

(and (frame-live-p (selected-frame))
     (window-live-p (selected-window))
     (eq (frame-selected-window (selected-frame))
         (selected-window)))

Whenever this basic invariant is violated, there is no guarantee that
frame and window management will produce correct results.  Currently,
this invariance is no longer guaranteed if Lisp code is allowed to
manipulate frames and windows arbitrarily while processing the mode line
or the frame title.  IMO there are three possible ways to deal with this
problem:

(1) Let the redisplay code handle it.

(2) Let the frame and window management handle it by disallowing such
operations while they are issued by the mode line or frame title
processing code.

(3) Ignore it and let the frame/window management routines catch up with
it later.

Using (1) way my initial idea.  The patch I proposed handles simple
cases like Madhu's bug.  It will certainly not handle more sophisticated
cases where, for example, an application kills two frames in a row.

(2) is by far the most simple and reliable approach but it will restrict
applications in what they are allowed to do when processing a mode line
or frame title.

(3) means that frame/window management proceeds in a non-deterministic
fashion as long as it has not detected that its basic invariant has been
violated.

> This isn't about trust.  This is about letting users' Lisp do anything
> they want as long as the results allow redisplay to continue after
> that Lisp returns.  I don't think it's right to disallow certain
> actions just because they _might_ cause problems.

You again care about redisplay only.  Which means that frame/window
management is second-class as far as safety is concerned.

>>   > No, they are there in cases where we simply don't know how to
>>   > continue.
>>
>> If that's the reason, then SELECTED_FRAME can easily set selected_frame
>> to some live frame and continue.
>
> Something like that, yes.

I attach a patch that does that.  If you try it with a recipe like
loading


(defvar foo
  '(:eval
    (when (> (length (frame-list)) 1)
      (delete-frame (next-frame)))))

(setq-default mode-line-format foo)

(make-frame)


with emacs -Q you will see that while it works around the crash it still
produces a

Wrong type argument: window-live-p, #<window 3>

error in redisplay.

martin

SELECTD_FRAME.diff
Description: Text Data