bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47207: 28.0.50; decode_next_window_args crash


From: Alan Mackenzie
Subject: bug#47207: 28.0.50; decode_next_window_args crash
Date: Tue, 13 Apr 2021 17:06:05 +0000

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 via email to

[Prev in Thread] Current Thread [Next in Thread]