all messages for Emacs-related lists mirrored at yhetil.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: Tue, 13 Apr 2021 17:06:05 +0000	[thread overview]
Message-ID: <YHXPfXQSx5Mt1JZv@ACM> (raw)
In-Reply-To: <b271888d-6273-d052-c788-505733bc1b72@gmx.at>

Hello, Martin.

On Tue, Apr 13, 2021 at 17:54:55 +0200, martin rudalics wrote:
>   and developers don't care.>> Because in my crash scenario (other-window 1 t) selects the tooltip
>  >> window.

>  > OK, then solving this issue will solve that as well, I guess.

> Having just managed to "solve this issue" here in a more or less elegant
> way, Alan beat me to it with a new twist.  To reproduce with emacs -Q do

> (custom-set-variables
>   '(tooltip-reuse-hidden-frame t)
>   '(x-gtk-use-system-tooltips nil))

> show a tooltip (by moving the mouse over the mode line for example) and
> then type C-h f followed by C-g.  Here this gets me

> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:399
> 399	  signal (sig, SIG_DFL);
> (gdb) bt
> #0  0x00000000005a6c28 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:399
> #1  0x0000000000653420 in die (msg=0x7d01d6 "WINDOWP (a)", file=0x7d01c3 "../../src/window.h", line=543) at ../../src/alloc.c:7420
> #2  0x00000000006006d2 in XWINDOW (a=XIL(0)) at ../../src/window.h:543
> #3  0x00000000006039ae in read_minibuf_unwind () at ../../src/minibuf.c:1060
> #4  0x000000000068e80e in do_one_unbind (this_binding=0x7fffffffc880, unwinding=true, bindflag=SET_INTERNAL_UNBIND) at ../../src/eval.c:3594
> #5  0x000000000068ebc9 in unbind_to (count=3, value=XIL(0)) at ../../src/eval.c:3717
> #6  0x00000000006877a5 in unwind_to_catch (catch=0xd99a40, type=NONLOCAL_EXIT_SIGNAL, value=XIL(0x2eb09c3)) at ../../src/eval.c:1254
> #7  0x0000000000688dda in signal_or_quit (error_symbol=XIL(0xb5e0), data=XIL(0), keyboard_quit=true) at ../../src/eval.c:1784
> #8  0x00000000006888df in quit () at ../../src/eval.c:1664
> #9  0x00000000005ad8c5 in recursive_edit_1 () at ../../src/keyboard.c:722
> #10 0x0000000000602e27 in read_minibuf (map=XIL(0x7ffff409d9f3), initial=XIL(0), prompt=XIL(0x10b6304), expflag=false, histvar=XIL(0x9ae0), histpos=make_fixnum(0), defalt=XIL(0x7ffff437cb7c), allow_props=false, inherit_input_method=false) at ../../src/minibuf.c:871
> #11 0x00000000006044a0 in Fread_from_minibuffer (prompt=XIL(0x10b6304), initial_contents=XIL(0), keymap=XIL(0x7ffff409d9f3), read=XIL(0), hist=XIL(0), default_value=XIL(0x7ffff437cb7c), inherit_input_method=XIL(0)) at ../../src/minibuf.c:1312
> #12 0x000000000068ca11 in funcall_subr (subr=0xc54d00 <Sread_from_minibuffer>, numargs=7, args=0x7fffffffcd70) at ../../src/eval.c:3011

[ .... ]

> Lisp Backtrace:
> "read-from-minibuffer" (0xffffcd70)
> "completing-read-default" (0xffffd2c8)
> "completing-read" (0xffffd448)
> "byte-code" (0xffffd8a0)
> "call-interactively" (0xffffdd40)
> "command-execute" (0xffffe2a8)
> (gdb)

> I can easily sidestep this in read_minibuf_unwind via

>    FOR_EACH_FRAME (frames, exp_MB_frame)
>      {
>        f = XFRAME (exp_MB_frame);
>        if (!FRAME_TOOLTIP_P (f))
> 	{
> 	  window = f->minibuffer_window;
> 	  w = XWINDOW (window);
> 	  if (EQ (w->frame, exp_MB_frame)
> 	      && EQ (w->contents, nth_minibuffer (minibuf_level)))
> 	    goto found;
> 	}
>      }

> but the underlying issue remains: Not every frame has a minibuffer
> window.

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.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2021-04-13 17:06 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 [this message]
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
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

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

  git send-email \
    --in-reply-to=YHXPfXQSx5Mt1JZv@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.