* bug#47207: 28.0.50; decode_next_window_args crash
@ 2021-03-17 8:45 martin rudalics
2021-03-17 13:29 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2021-03-17 8:45 UTC (permalink / raw)
To: 47207; +Cc: Alan Mackenzie
[-- Attachment #1: Type: text/plain, Size: 12301 bytes --]
The following bug has hit me out of the blue a couple of times. Trying
to ediff two buffers gets me the crash below:
#0 0x00000000005a5f85 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:379
#1 0x0000000000651df0 in die (msg=0x788ee1 "WINDOWP (a)", file=0x788ece "../../src/window.h", line=543) at ../../src/alloc.c:7420
#2 0x00000000004bdca6 in XWINDOW (a=XIL(0)) at ../../src/window.h:543
#3 0x00000000004c6a4d in decode_next_window_args (window=0x7fffffffa808, minibuf=0x7fffffffa800, all_frames=0x7fffffffa7f8) at ../../src/window.c:2891
#4 0x00000000004c6bff in next_window (window=XIL(0x2b04405), minibuf=XIL(0), all_frames=XIL(0x30), next_p=true) at ../../src/window.c:2927
#5 0x00000000004c7086 in Fnext_window (window=XIL(0x2b04405), minibuf=XIL(0), all_frames=XIL(0x30)) at ../../src/window.c:3023
#6 0x000000000068b298 in funcall_subr (subr=0xc4b6e0 <Snext_window>, numargs=3, args=0x7fffffffa9d0) at ../../src/eval.c:2996
#7 0x000000000068ad15 in Ffuncall (nargs=4, args=0x7fffffffa9c8) at ../../src/eval.c:2918
#8 0x00000000006e4865 in exec_byte_code (bytestr=XIL(0x7ffff3cc5764), vector=XIL(0x7ffff3cc5255), maxdepth=make_fixnum(12), args_template=make_fixnum(769), nargs=2, args=0x7fffffffaf68) at ../../src/bytecode.c:632
#9 0x000000000068b4cd in fetch_and_exec_byte_code (fun=XIL(0x7ffff3cc51fd), syms_left=make_fixnum(769), nargs=2, args=0x7fffffffaf58) at ../../src/eval.c:3040
#10 0x000000000068b953 in funcall_lambda (fun=XIL(0x7ffff3cc51fd), nargs=2, arg_vector=0x7fffffffaf58) at ../../src/eval.c:3121
#11 0x000000000068ad59 in Ffuncall (nargs=3, args=0x7fffffffaf50) at ../../src/eval.c:2920
#12 0x00000000006e4865 in exec_byte_code (bytestr=XIL(0x1b2c854), vector=XIL(0x1a0010d), maxdepth=make_fixnum(7), args_template=make_fixnum(256), nargs=0, args=0x7fffffffb4a0) at ../../src/bytecode.c:632
#13 0x000000000068b4cd in fetch_and_exec_byte_code (fun=XIL(0x1a001ad), syms_left=make_fixnum(256), nargs=0, args=0x7fffffffb4a0) at ../../src/eval.c:3040
#14 0x000000000068b953 in funcall_lambda (fun=XIL(0x1a001ad), nargs=0, arg_vector=0x7fffffffb4a0) at ../../src/eval.c:3121
#15 0x000000000068ad59 in Ffuncall (nargs=1, args=0x7fffffffb498) at ../../src/eval.c:2920
#16 0x00000000006e4865 in exec_byte_code (bytestr=XIL(0x1b09454), vector=XIL(0x1988f85), maxdepth=make_fixnum(9), args_template=make_fixnum(514), nargs=2, args=0x7fffffffba68) at ../../src/bytecode.c:632
#17 0x000000000068b4cd in fetch_and_exec_byte_code (fun=XIL(0x198906d), syms_left=make_fixnum(514), nargs=2, args=0x7fffffffba58) at ../../src/eval.c:3040
#18 0x000000000068b953 in funcall_lambda (fun=XIL(0x198906d), nargs=2, arg_vector=0x7fffffffba58) at ../../src/eval.c:3121
#19 0x000000000068ad59 in Ffuncall (nargs=3, args=0x7fffffffba50) at ../../src/eval.c:2920
#20 0x00000000006e4865 in exec_byte_code (bytestr=XIL(0x1b08c04), vector=XIL(0x1988ba5), maxdepth=make_fixnum(8), args_template=make_fixnum(771), nargs=3, args=0x7fffffffbfc0) at ../../src/bytecode.c:632
#21 0x000000000068b4cd in fetch_and_exec_byte_code (fun=XIL(0x1988c45), syms_left=make_fixnum(771), nargs=3, args=0x7fffffffbfa8) at ../../src/eval.c:3040
#22 0x000000000068b953 in funcall_lambda (fun=XIL(0x1988c45), nargs=3, arg_vector=0x7fffffffbfa8) at ../../src/eval.c:3121
#23 0x000000000068ad59 in Ffuncall (nargs=4, args=0x7fffffffbfa0) at ../../src/eval.c:2920
#24 0x00000000006e4865 in exec_byte_code (bytestr=XIL(0x1b41884), vector=XIL(0x1a037f5), maxdepth=make_fixnum(17), args_template=make_fixnum(2312), nargs=9, args=0x7fffffffcb10) at ../../src/bytecode.c:632
#25 0x000000000068b4cd in fetch_and_exec_byte_code (fun=XIL(0x1aa7c75), syms_left=make_fixnum(2312), nargs=9, args=0x7fffffffcac8) at ../../src/eval.c:3040
#26 0x000000000068b953 in funcall_lambda (fun=XIL(0x1aa7c75), nargs=9, arg_vector=0x7fffffffcac8) at ../../src/eval.c:3121
#27 0x000000000068ad59 in Ffuncall (nargs=10, args=0x7fffffffcac0) at ../../src/eval.c:2920
#28 0x00000000006e4865 in exec_byte_code (bytestr=XIL(0x1a187b4), vector=XIL(0x1123095), maxdepth=make_fixnum(25), args_template=make_fixnum(1541), nargs=5, args=0x7fffffffd0f8) at ../../src/bytecode.c:632
#29 0x000000000068b4cd in fetch_and_exec_byte_code (fun=XIL(0x112310d), syms_left=make_fixnum(1541), nargs=5, args=0x7fffffffd0d0) at ../../src/eval.c:3040
#30 0x000000000068b953 in funcall_lambda (fun=XIL(0x112310d), nargs=5, arg_vector=0x7fffffffd0d0) at ../../src/eval.c:3121
#31 0x000000000068ad59 in Ffuncall (nargs=6, args=0x7fffffffd0c8) at ../../src/eval.c:2920
#32 0x00000000006e4865 in exec_byte_code (bytestr=XIL(0x1a18a34), vector=XIL(0x1616e2d), maxdepth=make_fixnum(10), args_template=make_fixnum(1026), nargs=2, args=0x7fffffffd540) at ../../src/bytecode.c:632
#33 0x000000000068b4cd in fetch_and_exec_byte_code (fun=XIL(0x1a7257d), syms_left=make_fixnum(1026), nargs=2, args=0x7fffffffd530) at ../../src/eval.c:3040
#34 0x000000000068b953 in funcall_lambda (fun=XIL(0x1a7257d), nargs=2, arg_vector=0x7fffffffd530) at ../../src/eval.c:3121
#35 0x000000000068b677 in apply_lambda (fun=XIL(0x1a7257d), args=XIL(0x1afad93), count=9) at ../../src/eval.c:3065
#36 0x00000000006897c1 in eval_sub (form=XIL(0x1afadd3)) at ../../src/eval.c:2440
#37 0x000000000068391a in Fprogn (body=XIL(0)) at ../../src/eval.c:462
#38 0x000000000068be0a in funcall_lambda (fun=XIL(0x1afab83), nargs=0, arg_vector=0x0) at ../../src/eval.c:3188
#39 0x000000000068ae6c in Ffuncall (nargs=1, args=0x7fffffffda88) at ../../src/eval.c:2932
#40 0x000000000067ef12 in Ffuncall_interactively (nargs=1, args=0x7fffffffda88) at ../../src/callint.c:260
#41 0x000000000068b13f in funcall_subr (subr=0xc570a0 <Sfuncall_interactively>, numargs=1, args=0x7fffffffda88) at ../../src/eval.c:2971
#42 0x000000000068ad15 in Ffuncall (nargs=2, args=0x7fffffffda80) at ../../src/eval.c:2918
#43 0x0000000000689b16 in Fapply (nargs=3, args=0x7fffffffda80) at ../../src/eval.c:2501
#44 0x000000000067f39a in Fcall_interactively (function=XIL(0xd1edf0), record_flag=XIL(0), keys=XIL(0x7ffff437c805)) at ../../src/callint.c:353
#45 0x000000000068b298 in funcall_subr (subr=0xc570e0 <Scall_interactively>, numargs=3, args=0x7fffffffdd40) at ../../src/eval.c:2996
#46 0x000000000068ad15 in Ffuncall (nargs=4, args=0x7fffffffdd38) at ../../src/eval.c:2918
#47 0x00000000006e4865 in exec_byte_code (bytestr=XIL(0x7ffff3d7c80c), vector=XIL(0x7ffff3d7c125), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=1, args=0x7fffffffe2b0) at ../../src/bytecode.c:632
#48 0x000000000068b4cd in fetch_and_exec_byte_code (fun=XIL(0x7ffff3d7c0f5), syms_left=make_fixnum(1025), nargs=1, args=0x7fffffffe2a8) at ../../src/eval.c:3040
#49 0x000000000068b953 in funcall_lambda (fun=XIL(0x7ffff3d7c0f5), nargs=1, arg_vector=0x7fffffffe2a8) at ../../src/eval.c:3121
#50 0x000000000068ad59 in Ffuncall (nargs=2, args=0x7fffffffe2a0) at ../../src/eval.c:2920
#51 0x000000000068a645 in call1 (fn=XIL(0x4230), arg1=XIL(0xd1edf0)) at ../../src/eval.c:2778
#52 0x00000000005ade1b in command_loop_1 () at ../../src/keyboard.c:1466
#53 0x0000000000686b71 in internal_condition_case (bfun=0x5ad5c2 <command_loop_1>, handlers=XIL(0x90), hfun=0x5acbd1 <cmd_error>) at ../../src/eval.c:1443
#54 0x00000000005ad1a7 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1094
#55 0x0000000000685f7d in internal_catch (tag=XIL(0xd6b0), func=0x5ad17a <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1193
#56 0x00000000005ad145 in command_loop () at ../../src/keyboard.c:1073
#57 0x00000000005ac6b8 in recursive_edit_1 () at ../../src/keyboard.c:720
#58 0x00000000005ac8b0 in Frecursive_edit () at ../../src/keyboard.c:789
#59 0x00000000005a8787 in main (argc=1, argv=0x7fffffffe7c8) at ../../src/emacs.c:2050
Lisp Backtrace:
"next-window" (0xffffa9d0)
"other-window" (0xffffaf58)
"ediff-skip-unsuitable-frames" (0xffffb4a0)
"ediff-prepare-error-list" (0xffffba58)
"ediff-setup-diff-regions" (0xffffbfa8)
"ediff-setup" (0xffffcac8)
"ediff-buffers-internal" (0xffffd0d0)
"ediff-buffers" (0xffffd530)
"my-diffs-b" (0xffffda90)
"funcall-interactively" (0xffffda88)
"call-interactively" (0xffffdd40)
"command-execute" (0xffffe2a8)
(gdb) frame 3
#3 0x00000000004c6a4d in decode_next_wMajor mode: Text
Minor modes in effect:
pop-up-mini-mode: t
shell-dirtrack-mode: t
scroll-restore-mode: t
show-paren-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
temp-buffer-resize-mode: t
column-number-mode: t
line-number-mode: t
auto-fill-function: do-auto-fill
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow mail-extr warnings emacsbug message rmc puny rfc822 mml mml-sec
epa derived epg epg-config gnus-util rmail rmail-loaddefs auth-source
password-cache json map mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils smerge-mode diff mule-util eieio-opt
cl-extra speedbar ezimage dframe dabbrev etags fileloop generator xref
cl-seq project eieio eieio-core eieio-loaddefs minibuf-eldef time-date
subr-x shortdoc thingatpt help-fns radix-tree help-mode speck cl-macs
pop-up-mini vc cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs vc-git diff-mode vc-dispatcher
bug-reference elp ediff-vers ediff ediff-merg ediff-mult ediff-wind
ediff-diff ediff-help ediff-init ediff-util local-tags info-look
find-func elinfo-support elinfo texinfo info shell pcomplete comint
ansi-color ring sidebar bookmark seq byte-opt bytecomp byte-compile
cconv text-property-search sort m&d scroll-restore regexp-lock
time-stamp eldoc-tooltip pcase easy-mmode find-dired dired
dired-loaddefs cus-edit pp cus-start cus-load wid-edit cl-loaddefs
cl-lib jka-compr paren ls-lisp gv iso-transl tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 328334 70021)
(symbols 48 17143 1)
(strings 32 52277 4856)
(string-bytes 1 1699127)
(vectors 16 33942)
(vector-slots 8 1202337 161897)
(floats 8 170 554)
(intervals 56 19456 1549)
(buffers 1008 42))
indow_args (window=0x7fffffffa808, minibuf=0x7fffffffa800, all_frames=0x7fffffffa7f8) at ../../src/window.c:2891
2891 *minibuf = this_minibuffer_depth (XWINDOW (miniwin)->contents)
(gdb) p miniwin
$1 = XIL(0)
(gdb) frame 5
#5 0x00000000004c7086 in Fnext_window (window=XIL(0x2b04405), minibuf=XIL(0), all_frames=XIL(0x30)) at ../../src/window.c:3023
3023 return next_window (window, minibuf, all_frames, true);
(gdb) p window
$4 = XIL(0x2b04405)
(gdb) p XWINDOW (window)->contents
$5 = XIL(0x2d46a85)
(gdb) xpr
Lisp_Vectorlike
PVEC_BUFFER
$6 = (struct buffer *) 0x2d46a80
0x1fadde8 " *tip*"
(gdb)
Presumably, commit c7c154bb5756e0ae71d342c5d8aabf725877f186 is directly
responsible for the crash. It's triggered by the
(other-window 1 t)
call in `ediff-skip-unsuitable-frames' which selects the tooltip window
which has no minibuffer. Patch attached, but we probably should decide
whether to consider tooltip windows in `next-window' or `other-window'
at all. See also
https://lists.gnu.org/archive/html/emacs-devel/2018-02/msg00694.html
martin
[-- Attachment #2: window.c.diff --]
[-- Type: text/x-patch, Size: 972 bytes --]
diff --git a/src/window.c b/src/window.c
index eb16e2a433..6da804bbd9 100644
--- a/src/window.c
+++ b/src/window.c
@@ -2668,7 +2668,7 @@ decode_next_window_args (Lisp_Object *window, Lisp_Object *minibuf, Lisp_Object
XSETWINDOW (*window, w);
/* MINIBUF nil may or may not include minibuffers. Decide if it
does. */
- if (NILP (*minibuf))
+ if (WINDOWP (miniwin) & NILP (*minibuf))
*minibuf = this_minibuffer_depth (XWINDOW (miniwin)->contents)
? miniwin
: Qlambda;
@@ -2682,9 +2682,7 @@ decode_next_window_args (Lisp_Object *window, Lisp_Object *minibuf, Lisp_Object
/* ALL_FRAMES nil doesn't specify which frames to include. */
if (NILP (*all_frames))
*all_frames
- = (!EQ (*minibuf, Qlambda)
- ? FRAME_MINIBUF_WINDOW (XFRAME (w->frame))
- : Qnil);
+ = (WINDOWP (miniwin) && !EQ (*minibuf, Qlambda)) ? miniwin : Qnil;
else if (EQ (*all_frames, Qvisible))
;
else if (EQ (*all_frames, make_fixnum (0)))
^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
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
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2021-03-17 13:29 UTC (permalink / raw)
To: martin rudalics; +Cc: acm, 47207
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 17 Mar 2021 09:45:21 +0100
> Cc: Alan Mackenzie <acm@muc.de>
>
> The following bug has hit me out of the blue a couple of times. Trying
> to ediff two buffers gets me the crash below:
>
>
> #0 0x00000000005a5f85 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:379
> #1 0x0000000000651df0 in die (msg=0x788ee1 "WINDOWP (a)", file=0x788ece "../../src/window.h", line=543) at ../../src/alloc.c:7420
> #2 0x00000000004bdca6 in XWINDOW (a=XIL(0)) at ../../src/window.h:543
> #3 0x00000000004c6a4d in decode_next_window_args (window=0x7fffffffa808, minibuf=0x7fffffffa800, all_frames=0x7fffffffa7f8) at ../../src/window.c:2891
> #4 0x00000000004c6bff in next_window (window=XIL(0x2b04405), minibuf=XIL(0), all_frames=XIL(0x30), next_p=true) at ../../src/window.c:2927
Do you have local changes in window.c? The line numbers are about 200
lines off the current sources.
> we probably should decide whether to consider tooltip windows in
> `next-window' or `other-window' at all.
Not sure why. Don't we envision some applications that would like to
examine tooltip windows? IOW, that tooltip frames don't have a
minibuffer doesn't necessarily mean we don't want to give window
iterations access to tooltip windows.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-17 13:29 ` Eli Zaretskii
@ 2021-03-17 15:36 ` martin rudalics
2021-03-17 15:48 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2021-03-17 15:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, 47207
>> #0 0x00000000005a5f85 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:379
>> #1 0x0000000000651df0 in die (msg=0x788ee1 "WINDOWP (a)", file=0x788ece "../../src/window.h", line=543) at ../../src/alloc.c:7420
>> #2 0x00000000004bdca6 in XWINDOW (a=XIL(0)) at ../../src/window.h:543
>> #3 0x00000000004c6a4d in decode_next_window_args (window=0x7fffffffa808, minibuf=0x7fffffffa800, all_frames=0x7fffffffa7f8) at ../../src/window.c:2891
>> #4 0x00000000004c6bff in next_window (window=XIL(0x2b04405), minibuf=XIL(0), all_frames=XIL(0x30), next_p=true) at ../../src/window.c:2927
>
> Do you have local changes in window.c? The line numbers are about 200
> lines off the current sources.
Sorry. The following backtrace is from a fairly recent master.
Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:379
379 signal (sig, SIG_DFL);
(gdb) bt
#0 0x00000000005ac554 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:379
#1 0x0000000000658972 in die (msg=0x7900b9 "WINDOWP (a)", file=0x7900a6 "../../src/window.h", line=472) at ../../src/alloc.c:7420
#2 0x00000000004c6efc in XWINDOW (a=XIL(0)) at ../../src/window.h:472
#3 0x00000000004d1897 in decode_next_window_args (window=0x7fffffffa808, minibuf=0x7fffffffa800, all_frames=0x7fffffffa7f8) at ../../src/window.c:2672
#4 0x00000000004d1a49 in next_window (window=XIL(0x2abb4b5), minibuf=XIL(0), all_frames=XIL(0x30), next_p=true) at ../../src/window.c:2708
#5 0x00000000004d1ed0 in Fnext_window (window=XIL(0x2abb4b5), minibuf=XIL(0), all_frames=XIL(0x30)) at ../../src/window.c:2804
#6 0x0000000000691a93 in funcall_subr (subr=0xc52760 <Snext_window>, numargs=3, args=0x7fffffffa9d0) at ../../src/eval.c:2992
#7 0x0000000000691510 in Ffuncall (nargs=4, args=0x7fffffffa9c8) at ../../src/eval.c:2914
#8 0x00000000006eb040 in exec_byte_code (bytestr=XIL(0x7ffff40a9b14), vector=XIL(0x7ffff3cc7245), maxdepth=make_fixnum(12), args_template=make_fixnum(769), nargs=2, args=0x7fffffffaf68) at ../../src/bytecode.c:632
#9 0x0000000000691cc8 in fetch_and_exec_byte_code (fun=XIL(0x7ffff3cc71ed), syms_left=make_fixnum(769), nargs=2, args=0x7fffffffaf58) at ../../src/eval.c:3036
#10 0x000000000069214e in funcall_lambda (fun=XIL(0x7ffff3cc71ed), nargs=2, arg_vector=0x7fffffffaf58) at ../../src/eval.c:3117
#11 0x0000000000691554 in Ffuncall (nargs=3, args=0x7fffffffaf50) at ../../src/eval.c:2916
#12 0x00000000006eb040 in exec_byte_code (bytestr=XIL(0x1ab0764), vector=XIL(0x197fefd), maxdepth=make_fixnum(7), args_template=make_fixnum(256), nargs=0, args=0x7fffffffb4a0) at ../../src/bytecode.c:632
#13 0x0000000000691cc8 in fetch_and_exec_byte_code (fun=XIL(0x197ff9d), syms_left=make_fixnum(256), nargs=0, args=0x7fffffffb4a0) at ../../src/eval.c:3036
#14 0x000000000069214e in funcall_lambda (fun=XIL(0x197ff9d), nargs=0, arg_vector=0x7fffffffb4a0) at ../../src/eval.c:3117
#15 0x0000000000691554 in Ffuncall (nargs=1, args=0x7fffffffb498) at ../../src/eval.c:2916
#16 0x00000000006eb040 in exec_byte_code (bytestr=XIL(0x1a6ced4), vector=XIL(0x195e1f5), maxdepth=make_fixnum(9), args_template=make_fixnum(514), nargs=2, args=0x7fffffffba68) at ../../src/bytecode.c:632
#17 0x0000000000691cc8 in fetch_and_exec_byte_code (fun=XIL(0x195e2dd), syms_left=make_fixnum(514), nargs=2, args=0x7fffffffba58) at ../../src/eval.c:3036
#18 0x000000000069214e in funcall_lambda (fun=XIL(0x195e2dd), nargs=2, arg_vector=0x7fffffffba58) at ../../src/eval.c:3117
#19 0x0000000000691554 in Ffuncall (nargs=3, args=0x7fffffffba50) at ../../src/eval.c:2916
#20 0x00000000006eb040 in exec_byte_code (bytestr=XIL(0x1a0a974), vector=XIL(0x195ded5), maxdepth=make_fixnum(8), args_template=make_fixnum(771), nargs=3, args=0x7fffffffbfc0) at ../../src/bytecode.c:632
#21 0x0000000000691cc8 in fetch_and_exec_byte_code (fun=XIL(0x193f76d), syms_left=make_fixnum(771), nargs=3, args=0x7fffffffbfa8) at ../../src/eval.c:3036
#22 0x000000000069214e in funcall_lambda (fun=XIL(0x193f76d), nargs=3, arg_vector=0x7fffffffbfa8) at ../../src/eval.c:3117
#23 0x0000000000691554 in Ffuncall (nargs=4, args=0x7fffffffbfa0) at ../../src/eval.c:2916
#24 0x00000000006eb040 in exec_byte_code (bytestr=XIL(0x1acf284), vector=XIL(0x18d0a6d), maxdepth=make_fixnum(17), args_template=make_fixnum(2312), nargs=9, args=0x7fffffffcb10) at ../../src/bytecode.c:632
#25 0x0000000000691cc8 in fetch_and_exec_byte_code (fun=XIL(0x18d0e8d), syms_left=make_fixnum(2312), nargs=9, args=0x7fffffffcac8) at ../../src/eval.c:3036
#26 0x000000000069214e in funcall_lambda (fun=XIL(0x18d0e8d), nargs=9, arg_vector=0x7fffffffcac8) at ../../src/eval.c:3117
#27 0x0000000000691554 in Ffuncall (nargs=10, args=0x7fffffffcac0) at ../../src/eval.c:2916
#28 0x00000000006eb040 in exec_byte_code (bytestr=XIL(0x19cf9b4), vector=XIL(0x168d8b5), maxdepth=make_fixnum(25), args_template=make_fixnum(1541), nargs=5, args=0x7fffffffd0f8) at ../../src/bytecode.c:632
#29 0x0000000000691cc8 in fetch_and_exec_byte_code (fun=XIL(0x168d92d), syms_left=make_fixnum(1541), nargs=5, args=0x7fffffffd0d0) at ../../src/eval.c:3036
#30 0x000000000069214e in funcall_lambda (fun=XIL(0x168d92d), nargs=5, arg_vector=0x7fffffffd0d0) at ../../src/eval.c:3117
#31 0x0000000000691554 in Ffuncall (nargs=6, args=0x7fffffffd0c8) at ../../src/eval.c:2916
#32 0x00000000006eb040 in exec_byte_code (bytestr=XIL(0x19cfb94), vector=XIL(0x1172b95), maxdepth=make_fixnum(10), args_template=make_fixnum(1026), nargs=2, args=0x7fffffffd540) at ../../src/bytecode.c:632
#33 0x0000000000691cc8 in fetch_and_exec_byte_code (fun=XIL(0x1702115), syms_left=make_fixnum(1026), nargs=2, args=0x7fffffffd530) at ../../src/eval.c:3036
#34 0x000000000069214e in funcall_lambda (fun=XIL(0x1702115), nargs=2, arg_vector=0x7fffffffd530) at ../../src/eval.c:3117
#35 0x0000000000691e72 in apply_lambda (fun=XIL(0x1702115), args=XIL(0x1a76453), count=9) at ../../src/eval.c:3061
#36 0x000000000068ffbc in eval_sub (form=XIL(0x1a76493)) at ../../src/eval.c:2436
#37 0x000000000068a172 in Fprogn (body=XIL(0)) at ../../src/eval.c:462
#38 0x0000000000692605 in funcall_lambda (fun=XIL(0x1a58a53), nargs=0, arg_vector=0x0) at ../../src/eval.c:3184
#39 0x0000000000691667 in Ffuncall (nargs=1, args=0x7fffffffda88) at ../../src/eval.c:2928
#40 0x000000000068576a in Ffuncall_interactively (nargs=1, args=0x7fffffffda88) at ../../src/callint.c:260
#41 0x000000000069193a in funcall_subr (subr=0xc5dce0 <Sfuncall_interactively>, numargs=1, args=0x7fffffffda88) at ../../src/eval.c:2967
#42 0x0000000000691510 in Ffuncall (nargs=2, args=0x7fffffffda80) at ../../src/eval.c:2914
#43 0x0000000000690311 in Fapply (nargs=3, args=0x7fffffffda80) at ../../src/eval.c:2497
#44 0x0000000000685bf2 in Fcall_interactively (function=XIL(0xd0a900), record_flag=XIL(0), keys=XIL(0x7ffff437d235)) at ../../src/callint.c:353
#45 0x0000000000691a93 in funcall_subr (subr=0xc5dd20 <Scall_interactively>, numargs=3, args=0x7fffffffdd40) at ../../src/eval.c:2992
#46 0x0000000000691510 in Ffuncall (nargs=4, args=0x7fffffffdd38) at ../../src/eval.c:2914
#47 0x00000000006eb040 in exec_byte_code (bytestr=XIL(0x7ffff3d87ac4), vector=XIL(0x7ffff3d8772d), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=1, args=0x7fffffffe2b0) at ../../src/bytecode.c:632
#48 0x0000000000691cc8 in fetch_and_exec_byte_code (fun=XIL(0x7ffff3d876fd), syms_left=make_fixnum(1025), nargs=1, args=0x7fffffffe2a8) at ../../src/eval.c:3036
#49 0x000000000069214e in funcall_lambda (fun=XIL(0x7ffff3d876fd), nargs=1, arg_vector=0x7fffffffe2a8) at ../../src/eval.c:3117
#50 0x0000000000691554 in Ffuncall (nargs=2, args=0x7fffffffe2a0) at ../../src/eval.c:2916
#51 0x0000000000690e40 in call1 (fn=XIL(0x42f0), arg1=XIL(0xd0a900)) at ../../src/eval.c:2774
#52 0x00000000005b43ea in command_loop_1 () at ../../src/keyboard.c:1466
#53 0x000000000068d36c in internal_condition_case (bfun=0x5b3b91 <command_loop_1>, handlers=XIL(0x90), hfun=0x5b31a0 <cmd_error>) at ../../src/eval.c:1439
#54 0x00000000005b3776 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1094
#55 0x000000000068c778 in internal_catch (tag=XIL(0xd5f0), func=0x5b3749 <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1189
#56 0x00000000005b3714 in command_loop () at ../../src/keyboard.c:1073
#57 0x00000000005b2c87 in recursive_edit_1 () at ../../src/keyboard.c:720
#58 0x00000000005b2e7f in Frecursive_edit () at ../../src/keyboard.c:789
#59 0x00000000005aed56 in main (argc=1, argv=0x7fffffffe7c8) at ../../src/emacs.c:2050
Lisp Backtrace:
"next-window" (0xffffa9d0)
"other-window" (0xffffaf58)
"ediff-skip-unsuitable-frames" (0xffffb4a0)
"ediff-prepare-error-list" (0xffffba58)
"ediff-setup-diff-regions" (0xffffbfa8)
"ediff-setup" (0xffffcac8)
"ediff-buffers-internal" (0xffffd0d0)
"ediff-buffers" (0xffffd530)
"my-diffs-b" (0xffffda90)
"funcall-interactively" (0xffffda88)
"call-interactively" (0xffffdd40)
"command-execute" (0xffffe2a8)
(gdb) frame 3
#3 0x00000000004d1897 in decode_next_window_args (window=0x7fffffffa808, minibuf=0x7fffffffa800, all_frames=0x7fffffffa7f8) at ../../src/window.c:2672
2672 *minibuf = this_minibuffer_depth (XWINDOW (miniwin)->contents)
(gdb) p miniwin
$1 = XIL(0)
(gdb) frame 5
#5 0x00000000004d1ed0 in Fnext_window (window=XIL(0x2abb4b5), minibuf=XIL(0), all_frames=XIL(0x30)) at ../../src/window.c:2804
2804 return next_window (window, minibuf, all_frames, true);
(gdb) p XWINDOW (window)->contents
$2 = XIL(0x10f3195)
(gdb) xpr
Lisp_Vectorlike
PVEC_BUFFER
$3 = (struct buffer *) 0x10f3190
0x1db57b8 " *tip*"
(gdb)
>> we probably should decide whether to consider tooltip windows in
>> `next-window' or `other-window' at all.
>
> Not sure why. Don't we envision some applications that would like to
> examine tooltip windows? IOW, that tooltip frames don't have a
> minibuffer doesn't necessarily mean we don't want to give window
> iterations access to tooltip windows.
But then people must be always careful to never look into the minibuffer
window of a tooltip when writing C code. Think of minibuf.c's
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 ();
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-17 15:36 ` martin rudalics
@ 2021-03-17 15:48 ` Eli Zaretskii
2021-03-17 17:06 ` martin rudalics
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2021-03-17 15:48 UTC (permalink / raw)
To: martin rudalics; +Cc: acm, 47207
> Cc: 47207@debbugs.gnu.org, acm@muc.de
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 17 Mar 2021 16:36:53 +0100
>
> >> we probably should decide whether to consider tooltip windows in
> >> `next-window' or `other-window' at all.
> >
> > Not sure why. Don't we envision some applications that would like to
> > examine tooltip windows? IOW, that tooltip frames don't have a
> > minibuffer doesn't necessarily mean we don't want to give window
> > iterations access to tooltip windows.
>
> But then people must be always careful to never look into the minibuffer
> window of a tooltip when writing C code.
But the alternative is IMO much worse: there will be _no_ way
whatsoever to reach those windows via next_window.
The default is already not to consider those windows, so why it is a
problem that they are considered when the code explicitly requests to
consider _all_ the windows?
> Think of minibuf.c's
>
> 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 ();
That's about the selected-frame, and tooltip frames should never be
selected. Right?
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-17 15:48 ` Eli Zaretskii
@ 2021-03-17 17:06 ` martin rudalics
2021-03-17 17:47 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2021-03-17 17:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, 47207
> But the alternative is IMO much worse: there will be _no_ way
> whatsoever to reach those windows via next_window.
What would be bad about that?
> The default is already not to consider those windows, so why it is a
> problem that they are considered when the code explicitly requests to
> consider _all_ the windows?
>
>> Think of minibuf.c's
>>
>> 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 ();
>
> That's about the selected-frame, and tooltip frames should never be
> selected. Right?
How would we handle that suggestion in say `next-window-any-frame'?
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-17 17:06 ` martin rudalics
@ 2021-03-17 17:47 ` Eli Zaretskii
2021-03-17 18:01 ` martin rudalics
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2021-03-17 17:47 UTC (permalink / raw)
To: martin rudalics; +Cc: acm, 47207
> Cc: 47207@debbugs.gnu.org, acm@muc.de
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 17 Mar 2021 18:06:24 +0100
>
> > That's about the selected-frame, and tooltip frames should never be
> > selected. Right?
>
> How would we handle that suggestion in say `next-window-any-frame'?
Skip tooltip frames, I guess.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-17 17:47 ` Eli Zaretskii
@ 2021-03-17 18:01 ` martin rudalics
2021-03-17 18:15 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2021-03-17 18:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, 47207
>> How would we handle that suggestion in say `next-window-any-frame'?
>
> Skip tooltip frames, I guess.
But how if we don't want to do it in `next-frame'? Throwing an error in
`select-window' here would be a strange thing for a user. Checking
whether the returned frame is a tooltip frame in `next-window-any-frame'
means any Lisp code that does not do something similar can crash Emacs.
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-17 18:01 ` martin rudalics
@ 2021-03-17 18:15 ` Eli Zaretskii
2021-03-18 8:43 ` martin rudalics
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2021-03-17 18:15 UTC (permalink / raw)
To: martin rudalics; +Cc: acm, 47207
> Cc: 47207@debbugs.gnu.org, acm@muc.de
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 17 Mar 2021 19:01:26 +0100
>
> >> How would we handle that suggestion in say `next-window-any-frame'?
> >
> > Skip tooltip frames, I guess.
>
> But how if we don't want to do it in `next-frame'?
I don't think I understand what's bothering you. The idea is simple:
if you get a frame that's a tooltip frame, ask for another one.
> Checking whether the returned frame is a tooltip frame in
> `next-window-any-frame' means any Lisp code that does not do
> something similar can crash Emacs.
Crash how?
In any case, the idea that something applications might forget to do
would mean we must push the checks to lower levels sounds wrong to me.
Lower levels should be free from application-level constraints, so
that if someone wants to write code which breaks those constraints,
he/she could do that. That those who do it must know what they are
doing is a truism; restricting legitimate uses for fear of
illegitimate ones is punishing the innocent for fear of the evil --
that's the problem with TSA, for example.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-17 18:15 ` Eli Zaretskii
@ 2021-03-18 8:43 ` martin rudalics
2021-03-18 9:38 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2021-03-18 8:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, 47207
>> >> How would we handle that suggestion in say `next-window-any-frame'?
>> >
>> > Skip tooltip frames, I guess.
>>
>> But how if we don't want to do it in `next-frame'?
>
> I don't think I understand what's bothering you. The idea is simple:
> if you get a frame that's a tooltip frame, ask for another one.
Like the below, I suppose. The idea is simple ...
(defun next-window-any-frame ()
"Select the next window, regardless of which frame it is on."
(interactive)
(catch 'failed
(let ((selected (selected-window))
(next (next-window nil nil 0)))
(while (window-tooltip-p next)
(setq next (next-window next nil 0))
(when (eq next selected)
(throw 'failed nil)))
(select-window next)
(select-frame-set-input-focus (selected-frame)))))
... but we don't even have `window-tooltip-p' yet.
>> Checking whether the returned frame is a tooltip frame in
>> `next-window-any-frame' means any Lisp code that does not do
>> something similar can crash Emacs.
>
> Crash how?
As in my report. These were the only times I've been losing Emacs
sessions in the past years.
> In any case, the idea that something applications might forget to do
> would mean we must push the checks to lower levels sounds wrong to me.
> Lower levels should be free from application-level constraints, so
> that if someone wants to write code which breaks those constraints,
> he/she could do that.
Why did you decline the proposal to expose buffer markers to Elisp?
> That those who do it must know what they are
> doing is a truism; restricting legitimate uses for fear of
> illegitimate ones is punishing the innocent for fear of the evil --
> that's the problem with TSA, for example.
We still have no concept for whether and where we would refuse
selecting a tooltip window - in `select-window', select_window,
`select-frame', wherever we set selected_window ...
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-18 8:43 ` martin rudalics
@ 2021-03-18 9:38 ` Eli Zaretskii
2021-03-18 15:51 ` martin rudalics
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2021-03-18 9:38 UTC (permalink / raw)
To: martin rudalics; +Cc: acm, 47207
> Cc: 47207@debbugs.gnu.org, acm@muc.de
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 18 Mar 2021 09:43:57 +0100
>
> > I don't think I understand what's bothering you. The idea is simple:
> > if you get a frame that's a tooltip frame, ask for another one.
>
> Like the below, I suppose.
Something like that, yes.
> ... but we don't even have `window-tooltip-p' yet.
It's a one-liner, isn't it? I'm not even sure we need a function for
that, but I won't object adding one.
> >> Checking whether the returned frame is a tooltip frame in
> >> `next-window-any-frame' means any Lisp code that does not do
> >> something similar can crash Emacs.
> >
> > Crash how?
>
> As in my report. These were the only times I've been losing Emacs
> sessions in the past years.
If we didn't fix that yet, let's fix it ASAP.
> > In any case, the idea that something applications might forget to do
> > would mean we must push the checks to lower levels sounds wrong to me.
> > Lower levels should be free from application-level constraints, so
> > that if someone wants to write code which breaks those constraints,
> > he/she could do that.
>
> Why did you decline the proposal to expose buffer markers to Elisp?
How is that relevant to the present discussion?
> > That those who do it must know what they are
> > doing is a truism; restricting legitimate uses for fear of
> > illegitimate ones is punishing the innocent for fear of the evil --
> > that's the problem with TSA, for example.
>
> We still have no concept for whether and where we would refuse
> selecting a tooltip window - in `select-window', select_window,
> `select-frame', wherever we set selected_window ...
Then let's develop that concept. But again, how is this relevant to
the issue at hand?
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-18 9:38 ` Eli Zaretskii
@ 2021-03-18 15:51 ` martin rudalics
2021-03-18 16:49 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2021-03-18 15:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, 47207
>> ... but we don't even have `window-tooltip-p' yet.
>
> It's a one-liner, isn't it? I'm not even sure we need a function for
> that, but I won't object adding one.
What would you do instead?
>> Why did you decline the proposal to expose buffer markers to Elisp?
>
> How is that relevant to the present discussion?
>
>> > That those who do it must know what they are
>> > doing is a truism; restricting legitimate uses for fear of
>> > illegitimate ones is punishing the innocent for fear of the evil --
>> > that's the problem with TSA, for example.
I don't know what TSA is and its relevance to Emacs. But when Basil
proposed to add a function called `marker-list' you answered
Just reading the markers probably won't but do you really believe this
is the last word? How many hours will it take for someone to ask for
a primitive to set the C-level markers as well, or request the ability
to map a function over all the markers? If it's really needed, sure,
let's do it. But is it? Or are we doing that just because we can?
which ended up with Bug#35536 marked as wontifx. For me this is a
classic example of "punishing the innocent for fear of the evil".
>> We still have no concept for whether and where we would refuse
>> selecting a tooltip window - in `select-window', select_window,
>> `select-frame', wherever we set selected_window ...
>
> Then let's develop that concept. But again, how is this relevant to
> the issue at hand?
Because in my crash scenario (other-window 1 t) selects the tooltip
window.
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-03-18 15:51 ` martin rudalics
@ 2021-03-18 16:49 ` Eli Zaretskii
2021-04-13 15:54 ` martin rudalics
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2021-03-18 16:49 UTC (permalink / raw)
To: martin rudalics; +Cc: acm, 47207
> Cc: 47207@debbugs.gnu.org, acm@muc.de
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 18 Mar 2021 16:51:18 +0100
>
> >> ... but we don't even have `window-tooltip-p' yet.
> >
> > It's a one-liner, isn't it? I'm not even sure we need a function for
> > that, but I won't object adding one.
>
> What would you do instead?
(frame-parameter FRAME 'tooltip)
> >> Why did you decline the proposal to expose buffer markers to Elisp?
> >
> > How is that relevant to the present discussion?
> >
> >> > That those who do it must know what they are
> >> > doing is a truism; restricting legitimate uses for fear of
> >> > illegitimate ones is punishing the innocent for fear of the evil --
> >> > that's the problem with TSA, for example.
>
> I don't know what TSA is and its relevance to Emacs. But when Basil
> proposed to add a function called `marker-list' you answered
>
> Just reading the markers probably won't but do you really believe this
> is the last word? How many hours will it take for someone to ask for
> a primitive to set the C-level markers as well, or request the ability
> to map a function over all the markers? If it's really needed, sure,
> let's do it. But is it? Or are we doing that just because we can?
>
> which ended up with Bug#35536 marked as wontifx. For me this is a
> classic example of "punishing the innocent for fear of the evil".
The above was about _adding_ an interface. By contrast, here we are
talking about an interface that existed for eons. That makes the
world of difference for me.
> >> We still have no concept for whether and where we would refuse
> >> selecting a tooltip window - in `select-window', select_window,
> >> `select-frame', wherever we set selected_window ...
> >
> > Then let's develop that concept. But again, how is this relevant to
> > the issue at hand?
>
> 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
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:37 ` Gregory Heytings
0 siblings, 2 replies; 22+ messages in thread
From: martin rudalics @ 2021-04-13 15:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: acm, 47207
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
#13 0x000000000068c36c in Ffuncall (nargs=8, args=0x7fffffffcd68) at ../../src/eval.c:2918
#14 0x00000000006e6056 in exec_byte_code (bytestr=XIL(0x7ffff409e1d4), vector=XIL(0x7ffff3cc1d4d), maxdepth=make_fixnum(18), args_template=make_fixnum(2050), nargs=8, args=0x7fffffffd308) at ../../src/bytecode.c:632
#15 0x000000000068cb24 in fetch_and_exec_byte_code (fun=XIL(0x7ffff3cc1d1d), syms_left=make_fixnum(2050), nargs=8, args=0x7fffffffd2c8) at ../../src/eval.c:3040
#16 0x000000000068cfaa in funcall_lambda (fun=XIL(0x7ffff3cc1d1d), nargs=8, arg_vector=0x7fffffffd2c8) at ../../src/eval.c:3121
#17 0x000000000068c3b0 in Ffuncall (nargs=9, args=0x7fffffffd2c0) at ../../src/eval.c:2920
#18 0x000000000060630a in Fcompleting_read (prompt=XIL(0x10b6304), collection=XIL(0x39a2e0), predicate=XIL(0x10bc4ed), require_match=XIL(0x30), initial_input=XIL(0), hist=XIL(0), def=XIL(0x7ffff437cb7c), inherit_input_method=XIL(0)) at ../../src/minibuf.c:2030
#19 0x000000000068ca75 in funcall_subr (subr=0xc54f00 <Scompleting_read>, numargs=7, args=0x7fffffffd448) at ../../src/eval.c:3016
#20 0x000000000068c36c in Ffuncall (nargs=8, args=0x7fffffffd440) at ../../src/eval.c:2918
#21 0x00000000006e6056 in exec_byte_code (bytestr=XIL(0x2ea3994), vector=XIL(0x10bc51d), maxdepth=make_fixnum(10), args_template=XIL(0), nargs=0, args=0x0) at ../../src/bytecode.c:632
#22 0x00000000006e5336 in Fbyte_code (bytestr=XIL(0x2ea3994), vector=XIL(0x10bc51d), maxdepth=make_fixnum(10)) at ../../src/bytecode.c:334
#23 0x000000000068ac71 in eval_sub (form=XIL(0x2ea7223)) at ../../src/eval.c:2401
#24 0x000000000068a1a8 in Feval (form=XIL(0x2ea7223), lexical=XIL(0)) at ../../src/eval.c:2224
#25 0x000000000068089d in Fcall_interactively (function=XIL(0x7ffff3057730), record_flag=XIL(0), keys=XIL(0x7ffff4373cbd)) at ../../src/callint.c:334
#26 0x000000000068c8ef in funcall_subr (subr=0xc5a140 <Scall_interactively>, numargs=3, args=0x7fffffffdd40) at ../../src/eval.c:2996
#27 0x000000000068c36c in Ffuncall (nargs=4, args=0x7fffffffdd38) at ../../src/eval.c:2918
#28 0x00000000006e6056 in exec_byte_code (bytestr=XIL(0x7ffff3d6b42c), vector=XIL(0x7ffff3d6ad45), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=1, args=0x7fffffffe2b0) at ../../src/bytecode.c:632
#29 0x000000000068cb24 in fetch_and_exec_byte_code (fun=XIL(0x7ffff3d6ad15), syms_left=make_fixnum(1025), nargs=1, args=0x7fffffffe2a8) at ../../src/eval.c:3040
#30 0x000000000068cfaa in funcall_lambda (fun=XIL(0x7ffff3d6ad15), nargs=1, arg_vector=0x7fffffffe2a8) at ../../src/eval.c:3121
#31 0x000000000068c3b0 in Ffuncall (nargs=2, args=0x7fffffffe2a0) at ../../src/eval.c:2920
#32 0x000000000068bc9c in call1 (fn=XIL(0x4260), arg1=XIL(0x7ffff3057730)) at ../../src/eval.c:2778
#33 0x00000000005af009 in command_loop_1 () at ../../src/keyboard.c:1466
#34 0x00000000006881c8 in internal_condition_case (bfun=0x5ae7b0 <command_loop_1>, handlers=XIL(0x90), hfun=0x5addbf <cmd_error>) at ../../src/eval.c:1443
#35 0x00000000005ae395 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1094
#36 0x00000000006875d4 in internal_catch (tag=XIL(0xd7d0), func=0x5ae368 <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1193
#37 0x00000000005ae333 in command_loop () at ../../src/keyboard.c:1073
#38 0x00000000005ad8a6 in recursive_edit_1 () at ../../src/keyboard.c:720
#39 0x00000000005ada9e in Frecursive_edit () at ../../src/keyboard.c:789
#40 0x00000000005a9975 in main (argc=1, argv=0x7fffffffe7c8) at ../../src/emacs.c:2252
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.
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-04-13 15:54 ` martin rudalics
@ 2021-04-13 17:06 ` Alan Mackenzie
2021-04-13 17:12 ` martin rudalics
2021-04-13 17:37 ` Gregory Heytings
1 sibling, 1 reply; 22+ messages in thread
From: Alan Mackenzie @ 2021-04-13 17:06 UTC (permalink / raw)
To: martin rudalics; +Cc: 47207
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).
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-04-13 17:06 ` Alan Mackenzie
@ 2021-04-13 17:12 ` martin rudalics
2021-04-15 13:07 ` Alan Mackenzie
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2021-04-13 17:12 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 47207
> 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
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-04-13 15:54 ` martin rudalics
2021-04-13 17:06 ` Alan Mackenzie
@ 2021-04-13 17:37 ` Gregory Heytings
1 sibling, 0 replies; 22+ messages in thread
From: Gregory Heytings @ 2021-04-13 17:37 UTC (permalink / raw)
To: martin rudalics; +Cc: acm, 47207
>
> 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.
>
This is because of commit 7c2ebf6e23.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-04-13 17:12 ` martin rudalics
@ 2021-04-15 13:07 ` Alan Mackenzie
2021-04-15 14:45 ` martin rudalics
0 siblings, 1 reply; 22+ messages in thread
From: Alan Mackenzie @ 2021-04-15 13:07 UTC (permalink / raw)
To: martin rudalics; +Cc: acm, 47207
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).
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
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
0 siblings, 2 replies; 22+ messages in thread
From: martin rudalics @ 2021-04-15 14:45 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 47207
> 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.
> 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.
> 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.
> 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.
> 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). And please look
into Bug#47781 next.
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-04-15 14:45 ` martin rudalics
@ 2021-04-16 0:15 ` Gregory Heytings
2021-04-16 11:28 ` Alan Mackenzie
1 sibling, 0 replies; 22+ messages in thread
From: Gregory Heytings @ 2021-04-16 0:15 UTC (permalink / raw)
To: martin rudalics; +Cc: 47207
>> 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). And please look
> into Bug#47781 next.
>
Not with me, FWIW. The minibuffer was perfectly functional before commit
2ecbf4cfae. Backward incompatible changes and bugs were introduced since
then. The current state of affairs is rather sad; as you said, it's the
first time in several years that you've been losing Emacs sessions.
That's quite a high price for a small feature that nobody requested.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
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
1 sibling, 1 reply; 22+ messages in thread
From: Alan Mackenzie @ 2021-04-16 11:28 UTC (permalink / raw)
To: martin rudalics; +Cc: 47207
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).
^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-04-16 11:28 ` Alan Mackenzie
@ 2021-04-16 14:42 ` martin rudalics
2021-04-18 8:01 ` martin rudalics
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2021-04-16 14:42 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 47207
> 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.
It fixes that bug. I'll check in a fix for the original Bug#47207 in a
couple of days.
Thanks, martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#47207: 28.0.50; decode_next_window_args crash
2021-04-16 14:42 ` martin rudalics
@ 2021-04-18 8:01 ` martin rudalics
0 siblings, 0 replies; 22+ messages in thread
From: martin rudalics @ 2021-04-18 8:01 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 47207
tags 47207 fixed
close 47207 28.1
quit
> It fixes that bug. I'll check in a fix for the original Bug#47207 in a
> couple of days.
Done now. Closing this bug.
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2021-04-18 8:01 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2021-04-16 14:42 ` martin rudalics
2021-04-18 8:01 ` martin rudalics
2021-04-13 17:37 ` Gregory Heytings
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).