bug#47207: 28.0.50; decode_next_window_args crash

[Alan Mackenzie <acm@muc.de>]

Hello, Martin.

On Tue, Apr 13, 2021 at 19:12:41 +0200, martin rudalics wrote:
>  > OK.  There's a long-standing comment to the contrary in
>  > choose_minibuf_frame (src/minibuf.c):

>  >        /* I don't think that any frames may validly have a null
>  >         * minibuffer window anymore.  */

>  > , so it looks like that comment is no longer valid.  It needs
>  > changing/removing and the code it annotates seems to want fixing.  There
>  > might well be other places in the earlier part of minibuf.c that assume
>  > a non-null ->minibuffer_window.

>  > Either the ->minibuffer_window of tootip frames must be given a sensible
>  > non-null value (is this practicable and sensible?), or the code needs
>  > fixing to not assume it.

> See

> https://lists.gnu.org/archive/html/emacs-devel/2018-02/msg00694.html

That's quite an involved thread.  I've read through it, but can't
remember seeing a firm decision on how to fix the problem, or even if it
was fixed then.

The current problem in minibuf.c seems to be that we assume
f->minibuffer_window to be non-nil in several (~6) places, rather than
checking it.

In most of these places, if we detect NILP (f->m_w), we can simply skip
the action we were intending to take.  This is certainly the case in the
bit that gave you the trouble in read_minibuf_unwind, where we're
stepping through all frames looking for the expired minibuffer.

It might well be that we never call do_switch_frame to a tool-tip frame,
for example.  Do you know if this is the case?  This could save some
checking code.

So, where do we go from here?  I'm quite willing to make these changes
to minibuf.c.  Would that be OK with everybody else?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).