GNU bug report logs - #47207
28.0.50; decode_next_window_args crash

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47207 in the body.
You can then email your comments to 47207 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Cc: Alan Mackenzie <acm <at> muc.de>
Subject: 28.0.50; decode_next_window_args crash
Date: Wed, 17 Mar 2021 09:45:21 +0100

[Message part 1 (text/plain, inline)]

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

[window.c.diff (text/x-patch, attachment)]

Message #8 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Wed, 17 Mar 2021 15:29:32 +0200

> From: martin rudalics <rudalics <at> gmx.at>
> Date: Wed, 17 Mar 2021 09:45:21 +0100
> Cc: Alan Mackenzie <acm <at> 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.

Message #11 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Wed, 17 Mar 2021 16:36:53 +0100

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

Message #14 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Wed, 17 Mar 2021 17:48:50 +0200

> Cc: 47207 <at> debbugs.gnu.org, acm <at> muc.de
> From: martin rudalics <rudalics <at> 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?

Message #17 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Wed, 17 Mar 2021 18:06:24 +0100

> 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

Message #20 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Wed, 17 Mar 2021 19:47:22 +0200

> Cc: 47207 <at> debbugs.gnu.org, acm <at> muc.de
> From: martin rudalics <rudalics <at> 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.

Message #23 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
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'?  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

Message #26 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Wed, 17 Mar 2021 20:15:00 +0200

> Cc: 47207 <at> debbugs.gnu.org, acm <at> muc.de
> From: martin rudalics <rudalics <at> 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.

Message #29 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Thu, 18 Mar 2021 09:43:57 +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.

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

Message #32 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Thu, 18 Mar 2021 11:38:28 +0200

> Cc: 47207 <at> debbugs.gnu.org, acm <at> muc.de
> From: martin rudalics <rudalics <at> 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?

Message #35 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
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?

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

Message #38 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Thu, 18 Mar 2021 18:49:17 +0200

> Cc: 47207 <at> debbugs.gnu.org, acm <at> muc.de
> From: martin rudalics <rudalics <at> 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.

Message #41 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Tue, 13 Apr 2021 17:54:55 +0200

 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

Message #44 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47207 <at> debbugs.gnu.org
Subject: Re: 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).

Message #47 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Tue, 13 Apr 2021 19:12:41 +0200

> 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

Message #50 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Tue, 13 Apr 2021 17:37:33 +0000

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

Message #53 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Thu, 15 Apr 2021 13:07:31 +0000

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

Message #56 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Thu, 15 Apr 2021 16:45:20 +0200

> 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

Message #59 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Fri, 16 Apr 2021 00:15:13 +0000

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

Message #62 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Fri, 16 Apr 2021 11:28:50 +0000

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

Message #65 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Fri, 16 Apr 2021 16:42:47 +0200

> 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

Message #68 received at 47207 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 47207 <at> debbugs.gnu.org
Subject: Re: bug#47207: 28.0.50; decode_next_window_args crash
Date: Sun, 18 Apr 2021 10:01:53 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.