unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: martin rudalics <rudalics@gmx.at>
Cc: 47207@debbugs.gnu.org
Subject: bug#47207: 28.0.50; decode_next_window_args crash
Date: Fri, 16 Apr 2021 11:28:50 +0000	[thread overview]
Message-ID: <YHl08rLzz2tidQ+3@ACM> (raw)
In-Reply-To: <872ab30c-3492-b523-eb4a-2f33a6c5da56@gmx.at>

Hello, Martin.

On Thu, Apr 15, 2021 at 16:45:20 +0200, martin rudalics wrote:
>  > 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.

> It wasn't fixed then.

Ah.

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

> We assume that it is a live window.

Indeed, yes.

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

> The most secure way is to skip the action whenever f->minibuffer_window
> fails the WINDOW_LIVE_P check.

OK, DONE.

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

> I wrote some code that avoids that a tooltip window ever gets selected
> and do_switch_frame returns silently when asked to switch to a tooltip
> frame.  But I wouldn't rely on that - the display engine might still try
> to select a tooltip window for some reason.

OK.

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

> It would be OK with me (and should fix Bug#47774 too).

Could you please look at my patch (below).  It seems to fix the bug you
gave a recipe for a couple of posts back.  I'm hoping it can be
committed as it is.

> And please look into Bug#47781 next.

OK.



diff --git a/src/minibuf.c b/src/minibuf.c
index c9831fd50f..a3c1b99bf3 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -112,13 +112,15 @@ choose_minibuf_frame (void)
 {
   if (FRAMEP (selected_frame)
       && FRAME_LIVE_P (XFRAME (selected_frame))
+      && WINDOW_LIVE_P (XFRAME (selected_frame)->minibuffer_window)
       && !EQ (minibuf_window, XFRAME (selected_frame)->minibuffer_window))
     {
       struct frame *sf = XFRAME (selected_frame);
-      /* I don't think that any frames may validly have a null minibuffer
-	 window anymore.  */
-      if (NILP (sf->minibuffer_window))
-	emacs_abort ();
+      /* I don't think that any frames may validly have a null
+	 minibuffer window anymore.  (2021-04-15): Tooltip frames have
+	 a null MB.  Comment out the following.  */
+      /* if (NILP (sf->minibuffer_window)) */
+      /* 	emacs_abort (); */
 
       minibuf_window = sf->minibuffer_window;
     }
@@ -195,7 +197,9 @@ move_minibuffers_onto_frame (struct frame *of, bool for_deletion)
 	&& (for_deletion || minibuf_follows_frame () || FRAME_INITIAL_P (of))))
     return;
   if (FRAME_LIVE_P (f)
-      && !EQ (f->minibuffer_window, of->minibuffer_window))
+      && !EQ (f->minibuffer_window, of->minibuffer_window)
+      && WINDOW_LIVE_P (f->minibuffer_window) /* F not a tootip frame */
+      && WINDOW_LIVE_P (of->minibuffer_window))
     {
       zip_minibuffer_stacks (f->minibuffer_window, of->minibuffer_window);
       if (for_deletion && XFRAME (MB_frame) != of)
@@ -636,6 +640,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
 
   if (minibuf_level > 1
+      && WINDOW_LIVE_P (XFRAME (MB_frame)->minibuffer_window)
       && !EQ (XWINDOW (XFRAME (selected_frame)->minibuffer_window)->frame,
 	      MB_frame)
       && minibuf_moves_frame_when_opened ()
@@ -908,11 +913,13 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   unbind_to (count, Qnil);
 
   /* Switch the frame back to the calling frame.  */
-  if ((!EQ (selected_frame, calling_frame)
-       || !EQ (XWINDOW (XFRAME (calling_frame)->minibuffer_window)->frame,
-	       calling_frame))
-      && FRAMEP (calling_frame)
-      && FRAME_LIVE_P (XFRAME (calling_frame)))
+  if (FRAMEP (calling_frame)
+      && FRAME_LIVE_P (XFRAME (calling_frame))
+      && (!EQ (selected_frame, calling_frame)
+	  || (WINDOW_LIVE_P (XFRAME (calling_frame)->minibuffer_window)
+	      && !EQ (XWINDOW (XFRAME (calling_frame)->minibuffer_window)
+		      ->frame,
+		      calling_frame))))
     call2 (intern ("select-frame-set-input-focus"), calling_frame, Qnil);
 
   /* Add the value to the appropriate history list, if any.  This is
@@ -1056,10 +1063,13 @@ read_minibuf_unwind (void)
     {
       f = XFRAME (exp_MB_frame);
       window = f->minibuffer_window;
-      w = XWINDOW (window);
-      if (EQ (w->frame, exp_MB_frame)
-	  && EQ (w->contents, nth_minibuffer (minibuf_level)))
-	goto found;
+      if (WINDOW_LIVE_P (window))
+	{
+	  w = XWINDOW (window);
+	  if (EQ (w->frame, exp_MB_frame)
+	      && EQ (w->contents, nth_minibuffer (minibuf_level)))
+	    goto found;
+	}
     }
   return; /* expired minibuffer not found.  Maybe we should output an
 	     error, here. */


> martin

-- 
Alan Mackenzie (Nuremberg, Germany).





  parent reply	other threads:[~2021-04-16 11:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17  8:45 bug#47207: 28.0.50; decode_next_window_args crash martin rudalics
2021-03-17 13:29 ` Eli Zaretskii
2021-03-17 15:36   ` martin rudalics
2021-03-17 15:48     ` Eli Zaretskii
2021-03-17 17:06       ` martin rudalics
2021-03-17 17:47         ` Eli Zaretskii
2021-03-17 18:01           ` martin rudalics
2021-03-17 18:15             ` Eli Zaretskii
2021-03-18  8:43               ` martin rudalics
2021-03-18  9:38                 ` Eli Zaretskii
2021-03-18 15:51                   ` martin rudalics
2021-03-18 16:49                     ` Eli Zaretskii
2021-04-13 15:54                       ` martin rudalics
2021-04-13 17:06                         ` Alan Mackenzie
2021-04-13 17:12                           ` martin rudalics
2021-04-15 13:07                             ` Alan Mackenzie
2021-04-15 14:45                               ` martin rudalics
2021-04-16  0:15                                 ` Gregory Heytings
2021-04-16 11:28                                 ` Alan Mackenzie [this message]
2021-04-16 14:42                                   ` martin rudalics
2021-04-18  8:01                                     ` martin rudalics
2021-04-13 17:37                         ` Gregory Heytings

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YHl08rLzz2tidQ+3@ACM \
    --to=acm@muc.de \
    --cc=47207@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).