Package: emacs;
Reported by: Markus Triska <triska <at> metalevel.at>
Date: Sat, 3 Jan 2026 09:41:02 UTC
Severity: normal
Found in version 30.2
To reply to this bug, email your comments to 80120 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sat, 03 Jan 2026 09:41:02 GMT) Full text and rfc822 format available.Markus Triska <triska <at> metalevel.at>:bug-gnu-emacs <at> gnu.org.
(Sat, 03 Jan 2026 09:41:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Markus Triska <triska <at> metalevel.at> To: bug-gnu-emacs <at> gnu.org Subject: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sat, 03 Jan 2026 10:35:19 +0100 (CET)
Happy New Year!
Occasionally but not always, Emacs crashes in expose_window_tree,
yielding the backtrace shown below.
Please find below the outputs of "bt", "bt full" and—per instructions
of report-emacs-bug—"xbacktrace".
I will try to find a way to reproduce the crash reliably. Until such a
case is found, is the backtrace already useful? I would greatly
appreciate any help with this.
Thank you a lot, thank you for Emacs!
Markus
Program received signal SIGSEGV, Segmentation fault.
0x00005555556083db in expose_window_tree (w=0xfffffffffffffffb,
r=r <at> entry=0x7fffffffcc88) at xdisp.c:37021
37021 struct frame *f = XFRAME (w->frame);
(gdb) bt
#0 0x00005555556083db in expose_window_tree (w=0xfffffffffffffffb,
r=r <at> entry=0x7fffffffcc88) at xdisp.c:37021
#1 0x00005555556084cd in expose_frame (f=f <at> entry=0x55555c7e0fa0,
x=<optimized out>, y=<optimized out>, w=<optimized out>, h=<optimized out>)
at xdisp.c:37082
#2 0x00005555557e30ef in EmacsFrameExpose (widget=<optimized out>,
event=<optimized out>, region=<optimized out>) at widget.c:494
#3 0x00007ffff7dd1d13 in XtDispatchEventToWidget ()
from /lib/x86_64-linux-gnu/libXt.so.6
#4 0x00007ffff7dd2533 in ?? () from /lib/x86_64-linux-gnu/libXt.so.6
#5 0x00007ffff7dd26c1 in XtDispatchEvent ()
from /lib/x86_64-linux-gnu/libXt.so.6
#6 0x000055555568ea01 in handle_one_xevent (
dpyinfo=dpyinfo <at> entry=0x55555608f150, event=event <at> entry=0x7fffffffd2c0,
finish=finish <at> entry=0x7fffffffd2bc,
hold_quit=hold_quit <at> entry=0x7fffffffd3b0) at xterm.c:25588
#7 0x00005555556957b6 in XTread_socket (terminal=<optimized out>,
hold_quit=0x7fffffffd3b0) at xterm.c:25748
#8 0x00005555556b7ea1 in gobble_input () at keyboard.c:7919
#9 0x00005555556b81c5 in handle_async_input () at keyboard.c:8158
#10 process_pending_signals () at keyboard.c:8172
#11 0x000055555573fd6d in probably_quit () at eval.c:1794
#12 0x0000555555747a6d in maybe_quit () at /home/username/emacs-30.2/src/lisp.h:3946
--Type <RET> for more, q to quit, c to continue without paging--
#13 Fdelq (elt=elt <at> entry=0x55555c7e0fa5, list=<optimized out>) at fns.c:2089
#14 0x00005555555b2673 in delete_frame (frame=0x55555c7e0fa5, force=0x0)
at frame.c:2271
#15 0x00005555555b36a2 in Fdelete_frame (frame=<optimized out>,
force=<optimized out>) at frame.c:2516
#16 0x000055555578a65f in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at /home/username/emacs-30.2/src/lisp.h:2243
#17 0x0000555555741d46 in Ffuncall (nargs=nargs <at> entry=1,
args=args <at> entry=0x7ffff5800340) at eval.c:3093
#18 0x0000555555742258 in Fapply (nargs=2, args=0x7ffff5800340) at eval.c:2718
#19 0x000055555578a65f in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at /home/username/emacs-30.2/src/lisp.h:2243
#20 0x0000555555741d46 in Ffuncall (nargs=nargs <at> entry=2,
args=args <at> entry=0x7fffffffd7a8) at eval.c:3093
#21 0x000055555573a8be in Ffuncall_interactively (nargs=2, args=0x7fffffffd7a8)
at callint.c:250
#22 0x0000555555741d46 in Ffuncall (nargs=nargs <at> entry=3,
args=args <at> entry=0x7fffffffd7a0) at eval.c:3093
#23 0x000055555573bee2 in Fcall_interactively (function=<optimized out>,
record_flag=<optimized out>, keys=<optimized out>) at callint.c:789
#24 0x000055555578a65f in exec_byte_code (fun=<optimized out>,
--Type <RET> for more, q to quit, c to continue without paging--
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at /home/username/emacs-30.2/src/lisp.h:2243
#25 0x0000555555741d46 in Ffuncall (nargs=nargs <at> entry=2,
args=args <at> entry=0x7fffffffda60) at eval.c:3093
#26 0x00005555556c38f5 in command_loop_1 () at keyboard.c:1550
#27 0x000055555573d497 in internal_condition_case (
bfun=bfun <at> entry=0x5555556c3510 <command_loop_1>,
handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5555556b6b90 <cmd_error>)
at eval.c:1613
#28 0x00005555556aee7e in command_loop_2 (handlers=handlers <at> entry=0x90)
at keyboard.c:1168
#29 0x000055555573d3f1 in internal_catch (tag=tag <at> entry=0x11cd0,
func=func <at> entry=0x5555556aee50 <command_loop_2>, arg=arg <at> entry=0x90)
at eval.c:1292
#30 0x00005555556aee13 in command_loop () at keyboard.c:1146
#31 0x00005555556b6731 in recursive_edit_1 () at keyboard.c:754
#32 0x00005555556b6ac0 in Frecursive_edit () at keyboard.c:837
#33 0x000055555559dd25 in main (argc=2, argv=<optimized out>) at emacs.c:2646
(gdb) bt full
#0 0x00005555556083db in expose_window_tree (w=0xfffffffffffffffb, r=r <at> entry=0x7fffffffcc88) at xdisp.c:37021
f = <optimized out>
mouse_face_overwritten_p = <optimized out>
#1 0x00005555556084cd in expose_frame (f=f <at> entry=0x55555c7e0fa0, x=<optimized out>, y=<optimized out>, w=<optimized out>,
h=<optimized out>) at xdisp.c:37082
r = {x = 230, y = 90, width = 67, height = 51}
mouse_face_overwritten_p = false
#2 0x00005555557e30ef in EmacsFrameExpose (widget=<optimized out>, event=<optimized out>, region=<optimized out>)
at widget.c:494
ew = <optimized out>
f = 0x55555c7e0fa0
#3 0x00007ffff7dd1d13 in XtDispatchEventToWidget () from /lib/x86_64-linux-gnu/libXt.so.6
No symbol table info available.
#4 0x00007ffff7dd2533 in ?? () from /lib/x86_64-linux-gnu/libXt.so.6
No symbol table info available.
#5 0x00007ffff7dd26c1 in XtDispatchEvent () from /lib/x86_64-linux-gnu/libXt.so.6
No symbol table info available.
#6 0x000055555568ea01 in handle_one_xevent (dpyinfo=dpyinfo <at> entry=0x55555608f150, event=event <at> entry=0x7fffffffd2c0,
finish=finish <at> entry=0x7fffffffd2bc, hold_quit=hold_quit <at> entry=0x7fffffffd3b0) at xterm.c:25588
inev = {kind = NO_EVENT, ie = {kind = NO_EVENT, part = scroll_bar_nowhere, code = 0, modifiers = 0, x = 0x0, y = 0x0,
timestamp = 0, frame_or_window = 0x0, arg = 0x0, device = 0x30}, sie = {kind = NO_EVENT, dpyinfo = 0x0,
requestor = 0, selection = 0, target = 0, property = 0, time = 0}}
count = 0
do_help = 0
nbytes = 0
any = <optimized out>
f = 0x55555c7e0fa0
mouse_frame = <optimized out>
hlinfo = 0x55555608f240
compose_status = {compose_ptr = 0x0, chars_matched = 0}
configureEvent = {type = 0, xany = {type = 0, serial = 0, send_event = 0, display = 0x0, window = 0}, xkey = {type = 0,
serial = 0, send_event = 0, display = 0x0, window = 0, root = 0, subwindow = 0, time = 0, x = 0, y = 0, x_root = 0,
y_root = 0, state = 0, keycode = 0, same_screen = 0}, xbutton = {type = 0, serial = 0, send_event = 0,
display = 0x0, window = 0, root = 0, subwindow = 0, time = 0, x = 0, y = 0, x_root = 0, y_root = 0, state = 0,
button = 0, same_screen = 0}, xmotion = {type = 0, serial = 0, send_event = 0, display = 0x0, window = 0, root = 0,
subwindow = 0, time = 0, x = 0, y = 0, x_root = 0, y_root = 0, state = 0, is_hint = 0 '\000', same_screen = 0},
xcrossing = {type = 0, serial = 0, send_event = 0, display = 0x0, window = 0, root = 0, subwindow = 0, time = 0,
x = 0, y = 0, x_root = 0, y_root = 0, mode = 0, detail = 0, same_screen = 0, focus = 0, state = 1444160864},
xfocus = {type = 0, serial = 0, send_event = 0, display = 0x0, window = 0, mode = 0, detail = 0}, xexpose = {type = 0,
serial = 0, send_event = 0, display = 0x0, window = 0, x = 0, y = 0, width = 0, height = 0, count = 0},
xgraphicsexpose = {type = 0, serial = 0, send_event = 0, display = 0x0, drawable = 0, x = 0, y = 0, width = 0,
height = 0, count = 0, major_code = 0, minor_code = 0}, xnoexpose = {type = 0, serial = 0, send_event = 0,
display = 0x0, drawable = 0, major_code = 0, minor_code = 0}, xvisibility = {type = 0, serial = 0, send_event = 0,
display = 0x0, window = 0, state = 0}, xcreatewindow = {type = 0, serial = 0, send_event = 0, display = 0x0,
parent = 0, window = 0, x = 0, y = 0, width = 0, height = 0, border_width = 0, override_redirect = 0},
xdestroywindow = {type = 0, serial = 0, send_event = 0, display = 0x0, event = 0, window = 0}, xunmap = {type = 0,
serial = 0, send_event = 0, display = 0x0, event = 0, window = 0, from_configure = 0}, xmap = {type = 0, serial = 0,
send_event = 0, display = 0x0, event = 0, window = 0, override_redirect = 0}, xmaprequest = {type = 0, serial = 0,
send_event = 0, display = 0x0, parent = 0, window = 0}, xreparent = {type = 0, serial = 0, send_event = 0,
display = 0x0, event = 0, window = 0, parent = 0, x = 0, y = 0, override_redirect = 0}, xconfigure = {type = 0,
serial = 0, send_event = 0, display = 0x0, event = 0, window = 0, x = 0, y = 0, width = 0, height = 0,
border_width = 0, above = 0, override_redirect = 0}, xgravity = {type = 0, serial = 0, send_event = 0,
--Type <RET> for more, q to quit, c to continue without paging--
display = 0x0, event = 0, window = 0, x = 0, y = 0}, xresizerequest = {type = 0, serial = 0, send_event = 0,
display = 0x0, window = 0, width = 0, height = 0}, xconfigurerequest = {type = 0, serial = 0, send_event = 0,
display = 0x0, parent = 0, window = 0, x = 0, y = 0, width = 0, height = 0, border_width = 0, above = 0, detail = 0,
value_mask = 0}, xcirculate = {type = 0, serial = 0, send_event = 0, display = 0x0, event = 0, window = 0,
place = 0}, xcirculaterequest = {type = 0, serial = 0, send_event = 0, display = 0x0, parent = 0, window = 0,
place = 0}, xproperty = {type = 0, serial = 0, send_event = 0, display = 0x0, window = 0, atom = 0, time = 0,
state = 0}, xselectionclear = {type = 0, serial = 0, send_event = 0, display = 0x0, window = 0, selection = 0,
time = 0}, xselectionrequest = {type = 0, serial = 0, send_event = 0, display = 0x0, owner = 0, requestor = 0,
selection = 0, target = 0, property = 0, time = 0}, xselection = {type = 0, serial = 0, send_event = 0,
display = 0x0, requestor = 0, selection = 0, target = 0, property = 0, time = 0}, xcolormap = {type = 0, serial = 0,
send_event = 0, display = 0x0, window = 0, colormap = 0, new = 0, state = 0}, xclient = {type = 0, serial = 0,
send_event = 0, display = 0x0, window = 0, message_type = 0, format = 0, data = {b = '\000' <repeats 19 times>, s = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, l = {0, 0, 0, 0, 0}}}, xmapping = {type = 0, serial = 0, send_event = 0,
display = 0x0, window = 0, request = 0, first_keycode = 0, count = 0}, xerror = {type = 0, display = 0x0,
resourceid = 0, serial = 0, error_code = 0 '\000', request_code = 0 '\000', minor_code = 0 '\000'}, xkeymap = {
type = 0, serial = 0, send_event = 0, display = 0x0, window = 0, key_vector = '\000' <repeats 31 times>},
xgeneric = {type = 0, serial = 0, send_event = 0, display = 0x0, extension = 0, evtype = 0}, xcookie = {type = 0,
serial = 0, send_event = 0, display = 0x0, extension = 0, evtype = 0, cookie = 0, data = 0x0}, pad = {
0 <repeats 12 times>, 93825004741984, 140737352135744, 0, 168, 93825003998576, 0, 182964069214978721, 4311744512, 0,
168, 93825003998576, 140737340498318}}
next_event = {type = 1644727440, xany = {type = 1644727440, serial = 140737342610112, send_event = 0,
display = 0xffffffffffffffb0, window = 93825003893696}, xkey = {type = 1644727440, serial = 140737342610112,
send_event = 0, display = 0xffffffffffffffb0, window = 93825003893696, root = 140737341200045, subwindow = 47,
time = 306467884182208540, x = 0, y = 0, x_root = -146619943, y_root = 32767, state = 47, keycode = 0,
same_screen = -1145110500}, xbutton = {type = 1644727440, serial = 140737342610112, send_event = 0,
display = 0xffffffffffffffb0, window = 93825003893696, root = 140737341200045, subwindow = 47,
time = 306467884182208540, x = 0, y = 0, x_root = -146619943, y_root = 32767, state = 47, button = 0,
same_screen = -1145110500}, xmotion = {type = 1644727440, serial = 140737342610112, send_event = 0,
display = 0xffffffffffffffb0, window = 93825003893696, root = 140737341200045, subwindow = 47,
time = 306467884182208540, x = 0, y = 0, x_root = -146619943, y_root = 32767, state = 47, is_hint = 0 '\000',
same_screen = -1145110500}, xcrossing = {type = 1644727440, serial = 140737342610112, send_event = 0,
display = 0xffffffffffffffb0, window = 93825003893696, root = 140737341200045, subwindow = 47,
time = 306467884182208540, x = 0, y = 0, x_root = -146619943, y_root = 32767, mode = 47, detail = 0,
same_screen = -1145110500, focus = 71355114, state = 0}, xfocus = {type = 1644727440, serial = 140737342610112,
send_event = 0, display = 0xffffffffffffffb0, window = 93825003893696, mode = -147155283, detail = 32767},
xexpose = {type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0,
window = 93825003893696, x = -147155283, y = 32767, width = 47, height = 0, count = -1145110500}, xgraphicsexpose = {
type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0,
drawable = 93825003893696, x = -147155283, y = 32767, width = 47, height = 0, count = -1145110500,
major_code = 71355114, minor_code = 0}, xnoexpose = {type = 1644727440, serial = 140737342610112, send_event = 0,
display = 0xffffffffffffffb0, drawable = 93825003893696, major_code = -147155283, minor_code = 32767},
xvisibility = {type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0,
window = 93825003893696, state = -147155283}, xcreatewindow = {type = 1644727440, serial = 140737342610112,
send_event = 0, display = 0xffffffffffffffb0, parent = 93825003893696, window = 140737341200045, x = 47, y = 0,
width = -1145110500, height = 71355114, border_width = 0, override_redirect = 0}, xdestroywindow = {
type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, event = 93825003893696,
window = 140737341200045}, xunmap = {type = 1644727440, serial = 140737342610112, send_event = 0,
display = 0xffffffffffffffb0, event = 93825003893696, window = 140737341200045, from_configure = 47}, xmap = {
type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, event = 93825003893696,
window = 140737341200045, override_redirect = 47}, xmaprequest = {type = 1644727440, serial = 140737342610112,
send_event = 0, display = 0xffffffffffffffb0, parent = 93825003893696, window = 140737341200045}, xreparent = {
type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, event = 93825003893696,
--Type <RET> for more, q to quit, c to continue without paging--
window = 140737341200045, parent = 47, x = -1145110500, y = 71355114, override_redirect = 0}, xconfigure = {
type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, event = 93825003893696,
window = 140737341200045, x = 47, y = 0, width = -1145110500, height = 71355114, border_width = 0,
above = 140737341735385, override_redirect = 47}, xgravity = {type = 1644727440, serial = 140737342610112,
send_event = 0, display = 0xffffffffffffffb0, event = 93825003893696, window = 140737341200045, x = 47, y = 0},
xresizerequest = {type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0,
window = 93825003893696, width = -147155283, height = 32767}, xconfigurerequest = {type = 1644727440,
serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, parent = 93825003893696,
window = 140737341200045, x = 47, y = 0, width = -1145110500, height = 71355114, border_width = 0,
above = 140737341735385, detail = 47, value_mask = 306467884182208540}, xcirculate = {type = 1644727440,
serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, event = 93825003893696,
window = 140737341200045, place = 47}, xcirculaterequest = {type = 1644727440, serial = 140737342610112,
send_event = 0, display = 0xffffffffffffffb0, parent = 93825003893696, window = 140737341200045, place = 47},
xproperty = {type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0,
window = 93825003893696, atom = 140737341200045, time = 47, state = -1145110500}, xselectionclear = {
type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, window = 93825003893696,
selection = 140737341200045, time = 47}, xselectionrequest = {type = 1644727440, serial = 140737342610112,
send_event = 0, display = 0xffffffffffffffb0, owner = 93825003893696, requestor = 140737341200045, selection = 47,
target = 306467884182208540, property = 0, time = 140737341735385}, xselection = {type = 1644727440,
serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, requestor = 93825003893696,
selection = 140737341200045, target = 47, property = 306467884182208540, time = 0}, xcolormap = {type = 1644727440,
serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, window = 93825003893696,
colormap = 140737341200045, new = 47, state = 0}, xclient = {type = 1644727440, serial = 140737342610112,
send_event = 0, display = 0xffffffffffffffb0, window = 93825003893696, message_type = 140737341200045, format = 47,
data = {b = "\034\000\277\273\352\312@\004\000\000\000\000\000\000\000\000\331\301", <incomplete sequence \367>,
s = {28, -17473, -13590, 1088, 0, 0, 0, 0, -15911, -2238}, l = {306467884182208540, 0, 140737341735385, 47,
306467884182208540}}}, xmapping = {type = 1644727440, serial = 140737342610112, send_event = 0,
display = 0xffffffffffffffb0, window = 93825003893696, request = -147155283, first_keycode = 32767, count = 47},
xerror = {type = 1644727440, display = 0x7ffff7501ac0, resourceid = 0, serial = 18446744073709551536,
error_code = 192 '\300', request_code = 51 '3', minor_code = 7 '\a'}, xkeymap = {type = 1644727440,
serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0, window = 93825003893696,
key_vector = "\255\226:\367\377\177\000\000/\000\000\000\000\000\000\000\034\000\277\273\352\312@\004\000\000\000\000\000\000\000"}, xgeneric = {type = 1644727440, serial = 140737342610112, send_event = 0, display = 0xffffffffffffffb0,
extension = 1443312576, evtype = 21845}, xcookie = {type = 1644727440, serial = 140737342610112, send_event = 0,
display = 0xffffffffffffffb0, extension = 1443312576, evtype = 21845, cookie = 4147812013, data = 0x2f}, pad = {
93825205308560, 140737342610112, 0, -80, 93825003893696, 140737341200045, 47, 306467884182208540, 0,
140737341735385, 47, 306467884182208540, 0, 140737340499700, 32, 93825003898000, 0, -1, 93825003893812, 4096, 0, 0,
140737488343280, 1}}
coding = <optimized out>
dx = 0
dy = 0
sa_avail = 16384
sa_count = <optimized out>
#7 0x00005555556957b6 in XTread_socket (terminal=<optimized out>, hold_quit=0x7fffffffd3b0) at xterm.c:25748
finish = 0
event = {type = 12, xany = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, window = 71354774},
xkey = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, window = 71354774, root = 386547056870,
subwindow = 219043332163, time = 120259084288, x = 0, y = 0, x_root = 0, y_root = 0, state = 0, keycode = 55,
same_screen = 1}, xbutton = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140,
window = 71354774, root = 386547056870, subwindow = 219043332163, time = 120259084288, x = 0, y = 0, x_root = 0,
y_root = 0, state = 0, button = 55, same_screen = 1}, xmotion = {type = 12, serial = 375743, send_event = 0,
display = 0x555556072140, window = 71354774, root = 386547056870, subwindow = 219043332163, time = 120259084288,
--Type <RET> for more, q to quit, c to continue without paging--
x = 0, y = 0, x_root = 0, y_root = 0, state = 0, is_hint = 55 '7', same_screen = 1}, xcrossing = {type = 12,
serial = 375743, send_event = 0, display = 0x555556072140, window = 71354774, root = 386547056870,
subwindow = 219043332163, time = 120259084288, x = 0, y = 0, x_root = 0, y_root = 0, mode = 0, detail = 55,
same_screen = 1, focus = 0, state = 0}, xfocus = {type = 12, serial = 375743, send_event = 0,
display = 0x555556072140, window = 71354774, mode = 230, detail = 90}, xexpose = {type = 12, serial = 375743,
send_event = 0, display = 0x555556072140, window = 71354774, x = 230, y = 90, width = 67, height = 51, count = 0},
xgraphicsexpose = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, drawable = 71354774, x = 230,
y = 90, width = 67, height = 51, count = 0, major_code = 28, minor_code = 0}, xnoexpose = {type = 12,
serial = 375743, send_event = 0, display = 0x555556072140, drawable = 71354774, major_code = 230, minor_code = 90},
xvisibility = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, window = 71354774, state = 230},
xcreatewindow = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, parent = 71354774,
window = 386547056870, x = 67, y = 51, width = 0, height = 28, border_width = 0, override_redirect = 0},
xdestroywindow = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, event = 71354774,
window = 386547056870}, xunmap = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140,
event = 71354774, window = 386547056870, from_configure = 67}, xmap = {type = 12, serial = 375743, send_event = 0,
display = 0x555556072140, event = 71354774, window = 386547056870, override_redirect = 67}, xmaprequest = {
type = 12, serial = 375743, send_event = 0, display = 0x555556072140, parent = 71354774, window = 386547056870},
xreparent = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, event = 71354774,
window = 386547056870, parent = 219043332163, x = 0, y = 28, override_redirect = 0}, xconfigure = {type = 12,
serial = 375743, send_event = 0, display = 0x555556072140, event = 71354774, window = 386547056870, x = 67, y = 51,
width = 0, height = 28, border_width = 0, above = 0, override_redirect = 0}, xgravity = {type = 12, serial = 375743,
send_event = 0, display = 0x555556072140, event = 71354774, window = 386547056870, x = 67, y = 51},
xresizerequest = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, window = 71354774,
width = 230, height = 90}, xconfigurerequest = {type = 12, serial = 375743, send_event = 0,
display = 0x555556072140, parent = 71354774, window = 386547056870, x = 67, y = 51, width = 0, height = 28,
border_width = 0, above = 0, detail = 0, value_mask = 1}, xcirculate = {type = 12, serial = 375743, send_event = 0,
display = 0x555556072140, event = 71354774, window = 386547056870, place = 67}, xcirculaterequest = {type = 12,
serial = 375743, send_event = 0, display = 0x555556072140, parent = 71354774, window = 386547056870, place = 67},
xproperty = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, window = 71354774,
atom = 386547056870, time = 219043332163, state = 0}, xselectionclear = {type = 12, serial = 375743, send_event = 0,
display = 0x555556072140, window = 71354774, selection = 386547056870, time = 219043332163}, xselectionrequest = {
type = 12, serial = 375743, send_event = 0, display = 0x555556072140, owner = 71354774, requestor = 386547056870,
selection = 219043332163, target = 120259084288, property = 0, time = 0}, xselection = {type = 12, serial = 375743,
send_event = 0, display = 0x555556072140, requestor = 71354774, selection = 386547056870, target = 219043332163,
property = 120259084288, time = 0}, xcolormap = {type = 12, serial = 375743, send_event = 0,
display = 0x555556072140, window = 71354774, colormap = 386547056870, new = 67, state = 51}, xclient = {type = 12,
serial = 375743, send_event = 0, display = 0x555556072140, window = 71354774, message_type = 386547056870,
format = 67, data = {b = "\000\000\000\000\034", '\000' <repeats 14 times>, s = {0, 0, 28, 0, 0, 0, 0, 0, 0, 0},
l = {120259084288, 0, 0, 236223201280, 1}}}, xmapping = {type = 12, serial = 375743, send_event = 0,
display = 0x555556072140, window = 71354774, request = 230, first_keycode = 90, count = 67}, xerror = {type = 12,
display = 0x5bbbf, resourceid = 0, serial = 93825003888960, error_code = 150 '\226', request_code = 201 '\311',
minor_code = 64 '@'}, xkeymap = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140,
window = 71354774,
key_vector = "\346\000\000\000Z\000\000\000C\000\000\0003\000\000\000\000\000\000\000\034\000\000\000\000\000\000\000\000\000\000"}, xgeneric = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, extension = 71354774,
evtype = 0}, xcookie = {type = 12, serial = 375743, send_event = 0, display = 0x555556072140, extension = 71354774,
evtype = 0, cookie = 230, data = 0x3300000043}, pad = {12, 375743, 0, 93825003888960, 71354774, 386547056870,
219043332163, 120259084288, 0, 0, 236223201280, 1, 0, 0, 0, 0, 0, 0, 895, 0, 0, 844420635172768, 0,
4239037149336072704}}
count = 0
event_found = true
dpyinfo = 0x55555608f150
--Type <RET> for more, q to quit, c to continue without paging--
#8 0x00005555556b7ea1 in gobble_input () at keyboard.c:7919
nr = <optimized out>
hold_quit = {kind = NO_EVENT, part = scroll_bar_nowhere, code = 0, modifiers = 0, x = 0x0, y = 0x0, timestamp = 0,
frame_or_window = 0x0, arg = 0x0, device = 0x30}
next = 0x0
nread = 0
err = <optimized out>
t = 0x555555ecb298
#9 0x00005555556b81c5 in handle_async_input () at keyboard.c:8158
nread = <optimized out>
#10 process_pending_signals () at keyboard.c:8172
No locals.
#11 0x000055555573fd6d in probably_quit () at eval.c:1794
gc_count = <optimized out>
#12 0x0000555555747a6d in maybe_quit () at /home/username/emacs-30.2/src/lisp.h:3946
No locals.
#13 Fdelq (elt=elt <at> entry=0x55555c7e0fa5, list=<optimized out>) at fns.c:2089
li = {tortoise = 0x555564b2b1c3, max = 2, n = 0, q = 0}
prev = 0x7ffff61a5733
tail = <optimized out>
#14 0x00005555555b2673 in delete_frame (frame=0x55555c7e0fa5, force=0x0) at frame.c:2271
f = 0x55555c7e0fa0
sf = <optimized out>
kb = <optimized out>
frames = <optimized out>
frame1 = <optimized out>
is_tooltip_frame = <optimized out>
nochild = <optimized out>
minibuffer_child_frame = <optimized out>
ref = <optimized out>
#15 0x00005555555b36a2 in Fdelete_frame (frame=<optimized out>, force=<optimized out>) at frame.c:2516
No locals.
#16 0x000055555578a65f in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
args=<optimized out>) at /home/username/emacs-30.2/src/lisp.h:2243
call_nargs = 1
call_fun = <optimized out>
count1 = <optimized out>
val = <optimized out>
call_args = 0x7ffff58003c8
original_fun = 0x67e0
op = 1
type = <optimized out>
targets = {0x55555559a62e <exec_byte_code-2030690>, 0x55555578aa07 <exec_byte_code+1911>,
0x55555578aa02 <exec_byte_code+1906>, 0x55555578a9fd <exec_byte_code+1901>, 0x55555578a461 <exec_byte_code+465>,
0x55555578a461 <exec_byte_code+465>, 0x55555578a9c1 <exec_byte_code+1841>, 0x55555578a985 <exec_byte_code+1781>,
0x55555578c867 <exec_byte_code+9687>, 0x55555578c862 <exec_byte_code+9682>, 0x55555578c85d <exec_byte_code+9677>,
0x55555578c858 <exec_byte_code+9672>, 0x55555578a498 <exec_byte_code+520>, 0x55555578a4a0 <exec_byte_code+528>,
0x55555578c84a <exec_byte_code+9658>, 0x55555578c86c <exec_byte_code+9692>, 0x55555578c6ab <exec_byte_code+9243>,
0x55555578c6a6 <exec_byte_code+9238>, 0x55555578c6a1 <exec_byte_code+9233>, 0x55555578c69c <exec_byte_code+9228>,
0x55555578a3fb <exec_byte_code+363>, 0x55555578a400 <exec_byte_code+368>, 0x55555578c680 <exec_byte_code+9200>,
0x55555578c68e <exec_byte_code+9214>, 0x55555578c62f <exec_byte_code+9119>, 0x55555578c62a <exec_byte_code+9114>,
0x55555578c625 <exec_byte_code+9109>, 0x55555578c620 <exec_byte_code+9104>, 0x55555578a715 <exec_byte_code+1157>,
--Type <RET> for more, q to quit, c to continue without paging--
0x55555578a720 <exec_byte_code+1168>, 0x55555578c642 <exec_byte_code+9138>, 0x55555578c634 <exec_byte_code+9124>,
0x55555578c5ff <exec_byte_code+9071>, 0x55555578c5fa <exec_byte_code+9066>, 0x55555578c5f5 <exec_byte_code+9061>,
0x55555578c5f0 <exec_byte_code+9056>, 0x55555578a4fa <exec_byte_code+618>, 0x55555578a500 <exec_byte_code+624>,
0x55555578c612 <exec_byte_code+9090>, 0x55555578c604 <exec_byte_code+9076>, 0x55555578c5cf <exec_byte_code+9023>,
0x55555578c5ca <exec_byte_code+9018>, 0x55555578c5c5 <exec_byte_code+9013>, 0x55555578c5c0 <exec_byte_code+9008>,
0x55555578a6cf <exec_byte_code+1087>, 0x55555578a6d0 <exec_byte_code+1088>, 0x55555578c5e2 <exec_byte_code+9042>,
0x55555578c5d4 <exec_byte_code+9028>, 0x55555578c204 <exec_byte_code+8052>, 0x55555578c235 <exec_byte_code+8101>,
0x55555578c2a0 <exec_byte_code+8208>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555578c082 <exec_byte_code+7666>, 0x55555578c012 <exec_byte_code+7554>, 0x55555578bfd2 <exec_byte_code+7490>,
0x55555578bf92 <exec_byte_code+7426>, 0x55555578bf50 <exec_byte_code+7360>, 0x55555578c727 <exec_byte_code+9367>,
0x55555578c6ea <exec_byte_code+9306>, 0x55555578bf21 <exec_byte_code+7313>, 0x55555578c7d3 <exec_byte_code+9539>,
0x55555578c6b0 <exec_byte_code+9248>, 0x55555578bee4 <exec_byte_code+7252>, 0x55555578beb7 <exec_byte_code+7207>,
0x55555578be7a <exec_byte_code+7146>, 0x55555578be40 <exec_byte_code+7088>, 0x55555578be02 <exec_byte_code+7026>,
0x55555578bd91 <exec_byte_code+6913>, 0x55555578bd07 <exec_byte_code+6775>, 0x55555578bc76 <exec_byte_code+6630>,
0x55555578bc49 <exec_byte_code+6585>, 0x55555578bc1c <exec_byte_code+6540>, 0x55555578bbdf <exec_byte_code+6479>,
0x55555578bba2 <exec_byte_code+6418>, 0x55555578bb65 <exec_byte_code+6357>, 0x55555578bb24 <exec_byte_code+6292>,
0x55555578baed <exec_byte_code+6237>, 0x55555578bab6 <exec_byte_code+6182>, 0x55555578ba7f <exec_byte_code+6127>,
0x55555578b9e2 <exec_byte_code+5970>, 0x55555578b989 <exec_byte_code+5881>, 0x55555578b93a <exec_byte_code+5802>,
0x55555578b8e8 <exec_byte_code+5720>, 0x55555578b896 <exec_byte_code+5638>, 0x55555578b844 <exec_byte_code+5556>,
0x55555578b7f2 <exec_byte_code+5474>, 0x55555578b79c <exec_byte_code+5388>, 0x55555578b742 <exec_byte_code+5298>,
0x55555578b6ec <exec_byte_code+5212>, 0x55555578b696 <exec_byte_code+5126>, 0x55555578b640 <exec_byte_code+5040>,
0x55555578b5e9 <exec_byte_code+4953>, 0x55555578b4ff <exec_byte_code+4719>, 0x55555578a767 <exec_byte_code+1239>,
0x55555578b4d2 <exec_byte_code+4674>, 0x55555578b4a0 <exec_byte_code+4624>, 0x55555578b415 <exec_byte_code+4485>,
0x55555578b3ce <exec_byte_code+4414>, 0x55555578b3a1 <exec_byte_code+4369>, 0x55555578b372 <exec_byte_code+4322>,
0x55555578b343 <exec_byte_code+4275>, 0x55555578b30c <exec_byte_code+4220>, 0x55555578b2dd <exec_byte_code+4173>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578b2ae <exec_byte_code+4126>, 0x55555578b27f <exec_byte_code+4079>,
0x55555578b250 <exec_byte_code+4032>, 0x55555578b221 <exec_byte_code+3985>, 0x55555578b1f2 <exec_byte_code+3938>,
0x55555578b1c5 <exec_byte_code+3893>, 0x55555578a767 <exec_byte_code+1239>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555578b183 <exec_byte_code+3827>, 0x55555578b156 <exec_byte_code+3782>, 0x55555578b129 <exec_byte_code+3737>,
0x55555578b0ec <exec_byte_code+3676>, 0x55555578b0af <exec_byte_code+3615>, 0x55555578b082 <exec_byte_code+3570>,
0x55555578b055 <exec_byte_code+3525>, 0x55555578b018 <exec_byte_code+3464>, 0x55555578afdb <exec_byte_code+3403>,
0x55555578af9e <exec_byte_code+3342>, 0x55555578af6f <exec_byte_code+3295>, 0x55555578af42 <exec_byte_code+3250>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578c3a1 <exec_byte_code+8465>, 0x55555578c550 <exec_byte_code+8896>,
0x55555578c80d <exec_byte_code+9597>, 0x55555578c513 <exec_byte_code+8835>, 0x55555578c4d9 <exec_byte_code+8777>,
0x55555578c49f <exec_byte_code+8719>, 0x55555578c3fc <exec_byte_code+8556>, 0x55555578c3d9 <exec_byte_code+8521>,
0x55555578c650 <exec_byte_code+9152>, 0x55555578c37e <exec_byte_code+8430>, 0x55555578c31e <exec_byte_code+8334>,
0x55555578c2ec <exec_byte_code+8284>, 0x55555578c2a8 <exec_byte_code+8216>, 0x55555578c1b2 <exec_byte_code+7970>,
0x55555578c171 <exec_byte_code+7905>, 0x55555578c12a <exec_byte_code+7834>, 0x55555578c0d0 <exec_byte_code+7744>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578af01 <exec_byte_code+3185>, 0x55555578aed4 <exec_byte_code+3140>,
0x55555578aea7 <exec_byte_code+3095>, 0x55555578ae7a <exec_byte_code+3050>, 0x55555578ae4d <exec_byte_code+3005>,
0x55555578ae10 <exec_byte_code+2944>, 0x55555578add3 <exec_byte_code+2883>, 0x55555578ad96 <exec_byte_code+2822>,
0x55555578ad59 <exec_byte_code+2761>, 0x55555578ad04 <exec_byte_code+2676>, 0x55555578acc7 <exec_byte_code+2615>,
0x55555578ac8a <exec_byte_code+2554>, 0x55555578ac5c <exec_byte_code+2508>, 0x55555578abf9 <exec_byte_code+2409>,
0x55555578ab92 <exec_byte_code+2306>, 0x55555578ab57 <exec_byte_code+2247>, 0x55555578ab1c <exec_byte_code+2188>,
0x55555578aae4 <exec_byte_code+2132>, 0x55555578b593 <exec_byte_code+4867>, 0x55555578b546 <exec_byte_code+4790>,
0x55555578aa77 <exec_byte_code+2023>, 0x55555578aa0c <exec_byte_code+1916>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578bdbe <exec_byte_code+6958>, 0x55555578ba3b <exec_byte_code+6059>,
0x55555578b45c <exec_byte_code+4556>, 0x55555578a941 <exec_byte_code+1713>, 0x55555578a8fd <exec_byte_code+1645>,
--Type <RET> for more, q to quit, c to continue without paging--
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555578a8c6 <exec_byte_code+1590>, 0x55555578a865 <exec_byte_code+1493>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578a82d <exec_byte_code+1437> <repeats 64 times>}
quitcounter = <optimized out>
bc = 0x555555de7670 <main_thread+496>
top = 0x7ffff58003c0
pc = <optimized out>
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x555556281488
max_stack = <optimized out>
frame_base = <optimized out>
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
result = <optimized out>
#17 0x0000555555741d46 in Ffuncall (nargs=nargs <at> entry=1, args=args <at> entry=0x7ffff5800340) at eval.c:3093
count = <optimized out>
val = <optimized out>
#18 0x0000555555742258 in Fapply (nargs=2, args=0x7ffff5800340) at eval.c:2718
i = <optimized out>
funcall_nargs = <optimized out>
funcall_args = 0x0
spread_arg = <optimized out>
fun = 0x23c050
sa_avail = 16384
sa_count = {bytes = 1408}
numargs = <optimized out>
retval = <optimized out>
#19 0x000055555578a65f in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
args=<optimized out>) at /home/username/emacs-30.2/src/lisp.h:2243
call_nargs = 2
call_fun = <optimized out>
count1 = <optimized out>
val = <optimized out>
call_args = 0x7ffff5800340
original_fun = 0x3900
op = 2
type = <optimized out>
targets = {0x55555559a62e <exec_byte_code-2030690>, 0x55555578aa07 <exec_byte_code+1911>,
0x55555578aa02 <exec_byte_code+1906>, 0x55555578a9fd <exec_byte_code+1901>, 0x55555578a461 <exec_byte_code+465>,
0x55555578a461 <exec_byte_code+465>, 0x55555578a9c1 <exec_byte_code+1841>, 0x55555578a985 <exec_byte_code+1781>,
0x55555578c867 <exec_byte_code+9687>, 0x55555578c862 <exec_byte_code+9682>, 0x55555578c85d <exec_byte_code+9677>,
--Type <RET> for more, q to quit, c to continue without paging--
0x55555578c858 <exec_byte_code+9672>, 0x55555578a498 <exec_byte_code+520>, 0x55555578a4a0 <exec_byte_code+528>,
0x55555578c84a <exec_byte_code+9658>, 0x55555578c86c <exec_byte_code+9692>, 0x55555578c6ab <exec_byte_code+9243>,
0x55555578c6a6 <exec_byte_code+9238>, 0x55555578c6a1 <exec_byte_code+9233>, 0x55555578c69c <exec_byte_code+9228>,
0x55555578a3fb <exec_byte_code+363>, 0x55555578a400 <exec_byte_code+368>, 0x55555578c680 <exec_byte_code+9200>,
0x55555578c68e <exec_byte_code+9214>, 0x55555578c62f <exec_byte_code+9119>, 0x55555578c62a <exec_byte_code+9114>,
0x55555578c625 <exec_byte_code+9109>, 0x55555578c620 <exec_byte_code+9104>, 0x55555578a715 <exec_byte_code+1157>,
0x55555578a720 <exec_byte_code+1168>, 0x55555578c642 <exec_byte_code+9138>, 0x55555578c634 <exec_byte_code+9124>,
0x55555578c5ff <exec_byte_code+9071>, 0x55555578c5fa <exec_byte_code+9066>, 0x55555578c5f5 <exec_byte_code+9061>,
0x55555578c5f0 <exec_byte_code+9056>, 0x55555578a4fa <exec_byte_code+618>, 0x55555578a500 <exec_byte_code+624>,
0x55555578c612 <exec_byte_code+9090>, 0x55555578c604 <exec_byte_code+9076>, 0x55555578c5cf <exec_byte_code+9023>,
0x55555578c5ca <exec_byte_code+9018>, 0x55555578c5c5 <exec_byte_code+9013>, 0x55555578c5c0 <exec_byte_code+9008>,
0x55555578a6cf <exec_byte_code+1087>, 0x55555578a6d0 <exec_byte_code+1088>, 0x55555578c5e2 <exec_byte_code+9042>,
0x55555578c5d4 <exec_byte_code+9028>, 0x55555578c204 <exec_byte_code+8052>, 0x55555578c235 <exec_byte_code+8101>,
0x55555578c2a0 <exec_byte_code+8208>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555578c082 <exec_byte_code+7666>, 0x55555578c012 <exec_byte_code+7554>, 0x55555578bfd2 <exec_byte_code+7490>,
0x55555578bf92 <exec_byte_code+7426>, 0x55555578bf50 <exec_byte_code+7360>, 0x55555578c727 <exec_byte_code+9367>,
0x55555578c6ea <exec_byte_code+9306>, 0x55555578bf21 <exec_byte_code+7313>, 0x55555578c7d3 <exec_byte_code+9539>,
0x55555578c6b0 <exec_byte_code+9248>, 0x55555578bee4 <exec_byte_code+7252>, 0x55555578beb7 <exec_byte_code+7207>,
0x55555578be7a <exec_byte_code+7146>, 0x55555578be40 <exec_byte_code+7088>, 0x55555578be02 <exec_byte_code+7026>,
0x55555578bd91 <exec_byte_code+6913>, 0x55555578bd07 <exec_byte_code+6775>, 0x55555578bc76 <exec_byte_code+6630>,
0x55555578bc49 <exec_byte_code+6585>, 0x55555578bc1c <exec_byte_code+6540>, 0x55555578bbdf <exec_byte_code+6479>,
0x55555578bba2 <exec_byte_code+6418>, 0x55555578bb65 <exec_byte_code+6357>, 0x55555578bb24 <exec_byte_code+6292>,
0x55555578baed <exec_byte_code+6237>, 0x55555578bab6 <exec_byte_code+6182>, 0x55555578ba7f <exec_byte_code+6127>,
0x55555578b9e2 <exec_byte_code+5970>, 0x55555578b989 <exec_byte_code+5881>, 0x55555578b93a <exec_byte_code+5802>,
0x55555578b8e8 <exec_byte_code+5720>, 0x55555578b896 <exec_byte_code+5638>, 0x55555578b844 <exec_byte_code+5556>,
0x55555578b7f2 <exec_byte_code+5474>, 0x55555578b79c <exec_byte_code+5388>, 0x55555578b742 <exec_byte_code+5298>,
0x55555578b6ec <exec_byte_code+5212>, 0x55555578b696 <exec_byte_code+5126>, 0x55555578b640 <exec_byte_code+5040>,
0x55555578b5e9 <exec_byte_code+4953>, 0x55555578b4ff <exec_byte_code+4719>, 0x55555578a767 <exec_byte_code+1239>,
0x55555578b4d2 <exec_byte_code+4674>, 0x55555578b4a0 <exec_byte_code+4624>, 0x55555578b415 <exec_byte_code+4485>,
0x55555578b3ce <exec_byte_code+4414>, 0x55555578b3a1 <exec_byte_code+4369>, 0x55555578b372 <exec_byte_code+4322>,
0x55555578b343 <exec_byte_code+4275>, 0x55555578b30c <exec_byte_code+4220>, 0x55555578b2dd <exec_byte_code+4173>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578b2ae <exec_byte_code+4126>, 0x55555578b27f <exec_byte_code+4079>,
0x55555578b250 <exec_byte_code+4032>, 0x55555578b221 <exec_byte_code+3985>, 0x55555578b1f2 <exec_byte_code+3938>,
0x55555578b1c5 <exec_byte_code+3893>, 0x55555578a767 <exec_byte_code+1239>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555578b183 <exec_byte_code+3827>, 0x55555578b156 <exec_byte_code+3782>, 0x55555578b129 <exec_byte_code+3737>,
0x55555578b0ec <exec_byte_code+3676>, 0x55555578b0af <exec_byte_code+3615>, 0x55555578b082 <exec_byte_code+3570>,
0x55555578b055 <exec_byte_code+3525>, 0x55555578b018 <exec_byte_code+3464>, 0x55555578afdb <exec_byte_code+3403>,
0x55555578af9e <exec_byte_code+3342>, 0x55555578af6f <exec_byte_code+3295>, 0x55555578af42 <exec_byte_code+3250>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578c3a1 <exec_byte_code+8465>, 0x55555578c550 <exec_byte_code+8896>,
0x55555578c80d <exec_byte_code+9597>, 0x55555578c513 <exec_byte_code+8835>, 0x55555578c4d9 <exec_byte_code+8777>,
0x55555578c49f <exec_byte_code+8719>, 0x55555578c3fc <exec_byte_code+8556>, 0x55555578c3d9 <exec_byte_code+8521>,
0x55555578c650 <exec_byte_code+9152>, 0x55555578c37e <exec_byte_code+8430>, 0x55555578c31e <exec_byte_code+8334>,
0x55555578c2ec <exec_byte_code+8284>, 0x55555578c2a8 <exec_byte_code+8216>, 0x55555578c1b2 <exec_byte_code+7970>,
0x55555578c171 <exec_byte_code+7905>, 0x55555578c12a <exec_byte_code+7834>, 0x55555578c0d0 <exec_byte_code+7744>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578af01 <exec_byte_code+3185>, 0x55555578aed4 <exec_byte_code+3140>,
0x55555578aea7 <exec_byte_code+3095>, 0x55555578ae7a <exec_byte_code+3050>, 0x55555578ae4d <exec_byte_code+3005>,
0x55555578ae10 <exec_byte_code+2944>, 0x55555578add3 <exec_byte_code+2883>, 0x55555578ad96 <exec_byte_code+2822>,
0x55555578ad59 <exec_byte_code+2761>, 0x55555578ad04 <exec_byte_code+2676>, 0x55555578acc7 <exec_byte_code+2615>,
0x55555578ac8a <exec_byte_code+2554>, 0x55555578ac5c <exec_byte_code+2508>, 0x55555578abf9 <exec_byte_code+2409>,
0x55555578ab92 <exec_byte_code+2306>, 0x55555578ab57 <exec_byte_code+2247>, 0x55555578ab1c <exec_byte_code+2188>,
--Type <RET> for more, q to quit, c to continue without paging--
0x55555578aae4 <exec_byte_code+2132>, 0x55555578b593 <exec_byte_code+4867>, 0x55555578b546 <exec_byte_code+4790>,
0x55555578aa77 <exec_byte_code+2023>, 0x55555578aa0c <exec_byte_code+1916>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578bdbe <exec_byte_code+6958>, 0x55555578ba3b <exec_byte_code+6059>,
0x55555578b45c <exec_byte_code+4556>, 0x55555578a941 <exec_byte_code+1713>, 0x55555578a8fd <exec_byte_code+1645>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555578a8c6 <exec_byte_code+1590>, 0x55555578a865 <exec_byte_code+1493>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578a82d <exec_byte_code+1437> <repeats 64 times>}
quitcounter = <optimized out>
bc = 0x555555de7670 <main_thread+496>
top = 0x7ffff5800338
pc = <optimized out>
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x555556118770
max_stack = <optimized out>
frame_base = <optimized out>
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
result = <optimized out>
#20 0x0000555555741d46 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffd7a8) at eval.c:3093
count = <optimized out>
val = <optimized out>
#21 0x000055555573a8be in Ffuncall_interactively (nargs=2, args=0x7fffffffd7a8) at callint.c:250
speccount = <optimized out>
#22 0x0000555555741d46 in Ffuncall (nargs=nargs <at> entry=3, args=args <at> entry=0x7fffffffd7a0) at eval.c:3093
count = <optimized out>
val = <optimized out>
#23 0x000055555573bee2 in Fcall_interactively (function=<optimized out>, record_flag=<optimized out>, keys=<optimized out>)
at callint.c:789
speccount = <optimized out>
arg_from_tty = <optimized out>
key_count = <optimized out>
record_then_fail = <optimized out>
save_this_command = <optimized out>
save_this_original_command = <optimized out>
save_real_this_command = <optimized out>
save_last_command = <optimized out>
prefix_arg = <optimized out>
enable = <optimized out>
up_event = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
form = <optimized out>
specs = <optimized out>
sa_avail = <optimized out>
sa_count = <optimized out>
string_len = <optimized out>
string = <optimized out>
string_end = <optimized out>
next_event = <optimized out>
nargs = <optimized out>
args = <optimized out>
visargs = <optimized out>
varies = <optimized out>
tem = <optimized out>
val = <optimized out>
#24 0x000055555578a65f in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
args=<optimized out>) at /home/username/emacs-30.2/src/lisp.h:2243
call_nargs = 3
call_fun = <optimized out>
count1 = <optimized out>
val = <optimized out>
call_args = 0x7ffff57ff070
original_fun = 0x2aaaa04bdd10
op = 3
type = <optimized out>
targets = {0x55555559a62e <exec_byte_code-2030690>, 0x55555578aa07 <exec_byte_code+1911>,
0x55555578aa02 <exec_byte_code+1906>, 0x55555578a9fd <exec_byte_code+1901>, 0x55555578a461 <exec_byte_code+465>,
0x55555578a461 <exec_byte_code+465>, 0x55555578a9c1 <exec_byte_code+1841>, 0x55555578a985 <exec_byte_code+1781>,
0x55555578c867 <exec_byte_code+9687>, 0x55555578c862 <exec_byte_code+9682>, 0x55555578c85d <exec_byte_code+9677>,
0x55555578c858 <exec_byte_code+9672>, 0x55555578a498 <exec_byte_code+520>, 0x55555578a4a0 <exec_byte_code+528>,
0x55555578c84a <exec_byte_code+9658>, 0x55555578c86c <exec_byte_code+9692>, 0x55555578c6ab <exec_byte_code+9243>,
0x55555578c6a6 <exec_byte_code+9238>, 0x55555578c6a1 <exec_byte_code+9233>, 0x55555578c69c <exec_byte_code+9228>,
0x55555578a3fb <exec_byte_code+363>, 0x55555578a400 <exec_byte_code+368>, 0x55555578c680 <exec_byte_code+9200>,
0x55555578c68e <exec_byte_code+9214>, 0x55555578c62f <exec_byte_code+9119>, 0x55555578c62a <exec_byte_code+9114>,
0x55555578c625 <exec_byte_code+9109>, 0x55555578c620 <exec_byte_code+9104>, 0x55555578a715 <exec_byte_code+1157>,
0x55555578a720 <exec_byte_code+1168>, 0x55555578c642 <exec_byte_code+9138>, 0x55555578c634 <exec_byte_code+9124>,
0x55555578c5ff <exec_byte_code+9071>, 0x55555578c5fa <exec_byte_code+9066>, 0x55555578c5f5 <exec_byte_code+9061>,
0x55555578c5f0 <exec_byte_code+9056>, 0x55555578a4fa <exec_byte_code+618>, 0x55555578a500 <exec_byte_code+624>,
0x55555578c612 <exec_byte_code+9090>, 0x55555578c604 <exec_byte_code+9076>, 0x55555578c5cf <exec_byte_code+9023>,
0x55555578c5ca <exec_byte_code+9018>, 0x55555578c5c5 <exec_byte_code+9013>, 0x55555578c5c0 <exec_byte_code+9008>,
0x55555578a6cf <exec_byte_code+1087>, 0x55555578a6d0 <exec_byte_code+1088>, 0x55555578c5e2 <exec_byte_code+9042>,
0x55555578c5d4 <exec_byte_code+9028>, 0x55555578c204 <exec_byte_code+8052>, 0x55555578c235 <exec_byte_code+8101>,
0x55555578c2a0 <exec_byte_code+8208>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555578c082 <exec_byte_code+7666>, 0x55555578c012 <exec_byte_code+7554>, 0x55555578bfd2 <exec_byte_code+7490>,
0x55555578bf92 <exec_byte_code+7426>, 0x55555578bf50 <exec_byte_code+7360>, 0x55555578c727 <exec_byte_code+9367>,
0x55555578c6ea <exec_byte_code+9306>, 0x55555578bf21 <exec_byte_code+7313>, 0x55555578c7d3 <exec_byte_code+9539>,
0x55555578c6b0 <exec_byte_code+9248>, 0x55555578bee4 <exec_byte_code+7252>, 0x55555578beb7 <exec_byte_code+7207>,
0x55555578be7a <exec_byte_code+7146>, 0x55555578be40 <exec_byte_code+7088>, 0x55555578be02 <exec_byte_code+7026>,
0x55555578bd91 <exec_byte_code+6913>, 0x55555578bd07 <exec_byte_code+6775>, 0x55555578bc76 <exec_byte_code+6630>,
0x55555578bc49 <exec_byte_code+6585>, 0x55555578bc1c <exec_byte_code+6540>, 0x55555578bbdf <exec_byte_code+6479>,
0x55555578bba2 <exec_byte_code+6418>, 0x55555578bb65 <exec_byte_code+6357>, 0x55555578bb24 <exec_byte_code+6292>,
--Type <RET> for more, q to quit, c to continue without paging--
0x55555578baed <exec_byte_code+6237>, 0x55555578bab6 <exec_byte_code+6182>, 0x55555578ba7f <exec_byte_code+6127>,
0x55555578b9e2 <exec_byte_code+5970>, 0x55555578b989 <exec_byte_code+5881>, 0x55555578b93a <exec_byte_code+5802>,
0x55555578b8e8 <exec_byte_code+5720>, 0x55555578b896 <exec_byte_code+5638>, 0x55555578b844 <exec_byte_code+5556>,
0x55555578b7f2 <exec_byte_code+5474>, 0x55555578b79c <exec_byte_code+5388>, 0x55555578b742 <exec_byte_code+5298>,
0x55555578b6ec <exec_byte_code+5212>, 0x55555578b696 <exec_byte_code+5126>, 0x55555578b640 <exec_byte_code+5040>,
0x55555578b5e9 <exec_byte_code+4953>, 0x55555578b4ff <exec_byte_code+4719>, 0x55555578a767 <exec_byte_code+1239>,
0x55555578b4d2 <exec_byte_code+4674>, 0x55555578b4a0 <exec_byte_code+4624>, 0x55555578b415 <exec_byte_code+4485>,
0x55555578b3ce <exec_byte_code+4414>, 0x55555578b3a1 <exec_byte_code+4369>, 0x55555578b372 <exec_byte_code+4322>,
0x55555578b343 <exec_byte_code+4275>, 0x55555578b30c <exec_byte_code+4220>, 0x55555578b2dd <exec_byte_code+4173>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578b2ae <exec_byte_code+4126>, 0x55555578b27f <exec_byte_code+4079>,
0x55555578b250 <exec_byte_code+4032>, 0x55555578b221 <exec_byte_code+3985>, 0x55555578b1f2 <exec_byte_code+3938>,
0x55555578b1c5 <exec_byte_code+3893>, 0x55555578a767 <exec_byte_code+1239>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555578b183 <exec_byte_code+3827>, 0x55555578b156 <exec_byte_code+3782>, 0x55555578b129 <exec_byte_code+3737>,
0x55555578b0ec <exec_byte_code+3676>, 0x55555578b0af <exec_byte_code+3615>, 0x55555578b082 <exec_byte_code+3570>,
0x55555578b055 <exec_byte_code+3525>, 0x55555578b018 <exec_byte_code+3464>, 0x55555578afdb <exec_byte_code+3403>,
0x55555578af9e <exec_byte_code+3342>, 0x55555578af6f <exec_byte_code+3295>, 0x55555578af42 <exec_byte_code+3250>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578c3a1 <exec_byte_code+8465>, 0x55555578c550 <exec_byte_code+8896>,
0x55555578c80d <exec_byte_code+9597>, 0x55555578c513 <exec_byte_code+8835>, 0x55555578c4d9 <exec_byte_code+8777>,
0x55555578c49f <exec_byte_code+8719>, 0x55555578c3fc <exec_byte_code+8556>, 0x55555578c3d9 <exec_byte_code+8521>,
0x55555578c650 <exec_byte_code+9152>, 0x55555578c37e <exec_byte_code+8430>, 0x55555578c31e <exec_byte_code+8334>,
0x55555578c2ec <exec_byte_code+8284>, 0x55555578c2a8 <exec_byte_code+8216>, 0x55555578c1b2 <exec_byte_code+7970>,
0x55555578c171 <exec_byte_code+7905>, 0x55555578c12a <exec_byte_code+7834>, 0x55555578c0d0 <exec_byte_code+7744>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578af01 <exec_byte_code+3185>, 0x55555578aed4 <exec_byte_code+3140>,
0x55555578aea7 <exec_byte_code+3095>, 0x55555578ae7a <exec_byte_code+3050>, 0x55555578ae4d <exec_byte_code+3005>,
0x55555578ae10 <exec_byte_code+2944>, 0x55555578add3 <exec_byte_code+2883>, 0x55555578ad96 <exec_byte_code+2822>,
0x55555578ad59 <exec_byte_code+2761>, 0x55555578ad04 <exec_byte_code+2676>, 0x55555578acc7 <exec_byte_code+2615>,
0x55555578ac8a <exec_byte_code+2554>, 0x55555578ac5c <exec_byte_code+2508>, 0x55555578abf9 <exec_byte_code+2409>,
0x55555578ab92 <exec_byte_code+2306>, 0x55555578ab57 <exec_byte_code+2247>, 0x55555578ab1c <exec_byte_code+2188>,
0x55555578aae4 <exec_byte_code+2132>, 0x55555578b593 <exec_byte_code+4867>, 0x55555578b546 <exec_byte_code+4790>,
0x55555578aa77 <exec_byte_code+2023>, 0x55555578aa0c <exec_byte_code+1916>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578bdbe <exec_byte_code+6958>, 0x55555578ba3b <exec_byte_code+6059>,
0x55555578b45c <exec_byte_code+4556>, 0x55555578a941 <exec_byte_code+1713>, 0x55555578a8fd <exec_byte_code+1645>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555578a8c6 <exec_byte_code+1590>, 0x55555578a865 <exec_byte_code+1493>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555559a62e <exec_byte_code-2030690>,
0x55555559a62e <exec_byte_code-2030690>, 0x55555578a82d <exec_byte_code+1437> <repeats 64 times>}
quitcounter = <optimized out>
bc = 0x555555de7670 <main_thread+496>
top = 0x7ffff57ff068
pc = <optimized out>
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7ffff6a053a8
max_stack = <optimized out>
frame_base = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
result = <optimized out>
#25 0x0000555555741d46 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffda60) at eval.c:3093
count = <optimized out>
val = <optimized out>
#26 0x00005555556c38f5 in command_loop_1 () at keyboard.c:1550
scount = <optimized out>
cmd = <optimized out>
keybuf = {0x196, 0x62, 0x4141414141414141, 0x80, 0x7ffff682bcf5, 0xa0, 0x0, 0x80, 0x0, 0x7ffff682bcf0,
0x4000000012000000, 0x2aaaa09b8f00, 0x7fffffffdb90, 0x5555557405cf <eval_sub+671>, 0x0, 0x555555f16fc0,
0x2020202000000000, 0x20202020a09b8f00, 0x0, 0x60, 0x60, 0x7ffff61d8483, 0x0, 0x55555581f1c8, 0x7ffff6529545,
0x55555573e7f4 <unbind_to+244>, 0x0, 0x0, 0xb, 0xad10}
i = <optimized out>
last_pt = 27448
prev_modiff = 24295
prev_buffer = 0x5555564cdab0
#27 0x000055555573d497 in internal_condition_case (bfun=bfun <at> entry=0x5555556c3510 <command_loop_1>,
handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5555556b6b90 <cmd_error>) at eval.c:1613
val = <optimized out>
c = 0x555555f16fc0
#28 0x00005555556aee7e in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1168
val = <optimized out>
#29 0x000055555573d3f1 in internal_catch (tag=tag <at> entry=0x11cd0, func=func <at> entry=0x5555556aee50 <command_loop_2>,
arg=arg <at> entry=0x90) at eval.c:1292
val = <optimized out>
c = 0x555555f16e80
#30 0x00005555556aee13 in command_loop () at keyboard.c:1146
No locals.
#31 0x00005555556b6731 in recursive_edit_1 () at keyboard.c:754
count = <optimized out>
val = <optimized out>
#32 0x00005555556b6ac0 in Frecursive_edit () at keyboard.c:837
count = <optimized out>
buffer = <optimized out>
#33 0x000055555559dd25 in main (argc=2, argv=<optimized out>) at emacs.c:2646
stack_bottom_variable = 0x0
old_argc = <optimized out>
dump_file = 0x0
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
dump_mode = <optimized out>
skip_args = 0
temacs = 0x0
attempt_load_pdump = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
only_version = false
rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615}
lc_all = <optimized out>
sockfd = -1
module_assertions = <optimized out>
(gdb) xbacktrace
Undefined command: "xbacktrace". Try "help".
In GNU Emacs 30.2 (build 2, x86_64-pc-linux-gnu, X toolkit, Xaw scroll
bars) of 2025-09-03 built on beelink-ser8
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)
Configured using:
'configure --with-x-toolkit=lucid --with-tiff=ifavailable'
Configured features:
FREETYPE GIF GMP GNUTLS JPEG LIBXML2 MODULES NOTIFY INOTIFY PDUMPER
PNG SECCOMP SOUND THREADS TOOLKIT_SCROLL_BARS X11 XDBE XFT XIM XPM
LUCID ZLIB
Important settings:
value of $LC_MONETARY: de_AT.UTF-8
value of $LC_NUMERIC: de_AT.UTF-8
value of $LC_TIME: de_AT.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Features:
(shadow emacsbug message yank-media puny rfc822 mml mml-sec epa epg
rfc6068 epg-config gnus-util text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
misearch multi-isearch vc-git diff-mode track-changes easy-mmode vc
vc-dispatcher bug-reference thingatpt cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs dired-x
dired dired-loaddefs derived ediprolog rect ido rust-mode-autoloads
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
icons password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-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 font-core term/tty-colors frame minibuffer nadvice
seq simple cl-generic indonesian philippine 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 emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable
backquote threads inotify dynamic-setting font-render-setting
x-toolkit x multi-tty move-toolbar make-network-process emacs)
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sat, 03 Jan 2026 13:13:02 GMT) Full text and rfc822 format available.Message #8 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Markus Triska <triska <at> metalevel.at>, Po Lu <luangruo <at> yahoo.com>, martin rudalics <rudalics <at> gmx.at> Cc: 80120 <at> debbugs.gnu.org Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sat, 03 Jan 2026 15:12:15 +0200
> From: Markus Triska <triska <at> metalevel.at> > Date: Sat, 03 Jan 2026 10:35:19 +0100 (CET) > > Happy New Year! > > Occasionally but not always, Emacs crashes in expose_window_tree, > yielding the backtrace shown below. > > Please find below the outputs of "bt", "bt full" and—per instructions > of report-emacs-bug—"xbacktrace". > > I will try to find a way to reproduce the crash reliably. Until such a > case is found, is the backtrace already useful? I would greatly > appreciate any help with this. The backtrace tells us that the window passed to expose_window_tree: > #0 0x00005555556083db in expose_window_tree (w=0xfffffffffffffffb, <<<<<<< > r=r <at> entry=0x7fffffffcc88) at xdisp.c:37021 is bogus. Since expose_frame does this: > #1 0x00005555556084cd in expose_frame (f=f <at> entry=0x55555c7e0fa0, > x=<optimized out>, y=<optimized out>, w=<optimized out>, h=<optimized out>) > at xdisp.c:37082 mouse_face_overwritten_p = expose_window_tree (XWINDOW (f->root_window), &r); it follows that this frame's root window is garbled, or maybe the frame itself (which comes from EmacsFrameExpose): > #2 0x00005555557e30ef in EmacsFrameExpose (widget=<optimized out>, > event=<optimized out>, region=<optimized out>) at widget.c:494 is also bogus. (However, this frame is used in expose_frame with no problems, so maybe the frame is okay.) Does anyone have any idea what is going on here?
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sat, 03 Jan 2026 13:48:03 GMT) Full text and rfc822 format available.Message #11 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Po Lu <luangruo <at> yahoo.com>, martin rudalics <rudalics <at> gmx.at>, 80120 <at> debbugs.gnu.org, Markus Triska <triska <at> metalevel.at> Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sat, 03 Jan 2026 14:47:29 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Markus Triska <triska <at> metalevel.at>
>> Date: Sat, 03 Jan 2026 10:35:19 +0100 (CET)
>>
>> Happy New Year!
>>
>> Occasionally but not always, Emacs crashes in expose_window_tree,
>> yielding the backtrace shown below.
>>
>> Please find below the outputs of "bt", "bt full" and—per instructions
>> of report-emacs-bug—"xbacktrace".
>>
>> I will try to find a way to reproduce the crash reliably. Until such a
>> case is found, is the backtrace already useful? I would greatly
>> appreciate any help with this.
>
> The backtrace tells us that the window passed to expose_window_tree:
>
>> #0 0x00005555556083db in expose_window_tree (w=0xfffffffffffffffb, <<<<<<<
>> r=r <at> entry=0x7fffffffcc88) at xdisp.c:37021
>
> is bogus. Since expose_frame does this:
>
>> #1 0x00005555556084cd in expose_frame (f=f <at> entry=0x55555c7e0fa0,
>> x=<optimized out>, y=<optimized out>, w=<optimized out>, h=<optimized out>)
>> at xdisp.c:37082
>
> mouse_face_overwritten_p = expose_window_tree (XWINDOW (f->root_window), &r);
>
> it follows that this frame's root window is garbled, or maybe the
> frame itself (which comes from EmacsFrameExpose):
>
>> #2 0x00005555557e30ef in EmacsFrameExpose (widget=<optimized out>,
>> event=<optimized out>, region=<optimized out>) at widget.c:494
>
> is also bogus. (However, this frame is used in expose_frame with no
> problems, so maybe the frame is okay.)
>
> Does anyone have any idea what is going on here?
Further up in the backtrace
#12 0x0000555555747a6d in maybe_quit () at /home/username/emacs-30.2/src/lisp.h:3946
--Type <RET> for more, q to quit, c to continue without paging--
#13 Fdelq (elt=elt <at> entry=0x55555c7e0fa5, list=<optimized out>) at fns.c:2089
#14 0x00005555555b2673 in delete_frame (frame=0x55555c7e0fa5, force=0x0)
at frame.c:2271
Maybe it's the frame being deleted, and it's already window-less or something?
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sat, 03 Jan 2026 16:19:01 GMT) Full text and rfc822 format available.Message #14 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org>, Markus Triska <triska <at> metalevel.at>, Po Lu <luangruo <at> yahoo.com> Cc: 80120 <at> debbugs.gnu.org Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sat, 3 Jan 2026 17:18:17 +0100
> Does anyone have any idea what is going on here?
#10 process_pending_signals () at keyboard.c:8172
#11 0x000055555573fd6d in probably_quit () at eval.c:1794
#12 0x0000555555747a6d in maybe_quit () at
/home/username/emacs-30.2/src/lisp.h:3946
--Type <RET> for more, q to quit, c to continue without paging--
#13 Fdelq (elt=elt <at> entry=0x55555c7e0fa5, list=<optimized out>) at fns.c:2089
#14 0x00005555555b2673 in delete_frame (frame=0x55555c7e0fa5, force=0x0)
at frame.c:2271
#15 0x00005555555b36a2 in Fdelete_frame (frame=<optimized out>,
force=<optimized out>) at frame.c:2516
The frame is not removed from the frame list. It shouldn't use Fdelq
since if the frame list ever became circular we'd have a more serious
chaos than the one see here.
martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sat, 03 Jan 2026 20:23:01 GMT) Full text and rfc822 format available.Message #17 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sat, 03 Jan 2026 22:22:00 +0200
> Date: Sat, 3 Jan 2026 17:18:17 +0100 > Cc: 80120 <at> debbugs.gnu.org > From: martin rudalics <rudalics <at> gmx.at> > > > Does anyone have any idea what is going on here? > > #10 process_pending_signals () at keyboard.c:8172 > #11 0x000055555573fd6d in probably_quit () at eval.c:1794 > #12 0x0000555555747a6d in maybe_quit () at > /home/username/emacs-30.2/src/lisp.h:3946 > --Type <RET> for more, q to quit, c to continue without paging-- > #13 Fdelq (elt=elt <at> entry=0x55555c7e0fa5, list=<optimized out>) at fns.c:2089 > #14 0x00005555555b2673 in delete_frame (frame=0x55555c7e0fa5, force=0x0) > at frame.c:2271 > #15 0x00005555555b36a2 in Fdelete_frame (frame=<optimized out>, > force=<optimized out>) at frame.c:2516 > > The frame is not removed from the frame list. It shouldn't use Fdelq > since if the frame list ever became circular we'd have a more serious > chaos than the one see here. Thanks. I don't see where in delete_frame we call maybe_quit, so it's hard for me to know whether it's before or after we set its terminal to zero. If after, testing FRAME_LIVE_P in expose_frame will fix this. If not, we need to understand where and how maybe_quit is being called, and prevent that. I don't think I follow you when you talk about Fdelq. Are you saying that it's where we call maybe_quit?
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sat, 03 Jan 2026 23:09:02 GMT) Full text and rfc822 format available.Message #20 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 00:08:34 +0100
> I don't see where in delete_frame we call maybe_quit, It's before on line 3619 ... > so it's hard for > me to know whether it's before or after we set its terminal to zero. ... which is after on line 3656 of frame.c. > If after, testing FRAME_LIVE_P in expose_frame will fix this. If not, > we need to understand where and how maybe_quit is being called, and > prevent that. > > I don't think I follow you when you talk about Fdelq. Are you saying > that it's where we call maybe_quit? Yes. delete_frame has this block block_input (); Vframe_list = Fdelq (frame, Vframe_list); unblock_input (); and IIRC we blocked input here because we had a similar problem already. But Fdelq runs FOR_EACH_TAIL (tail) which is defined as FOR_EACH_TAIL_INTERNAL (tail, circular_list (tail), true) where the last argument is CHECK_QUIT and FOR_EACH_TAIL_INTERNAL has || ((check_quit) ? maybe_quit () : (void) 0, 0 < --li.n) \ so the frame to be deleted remains on the frame list if this really quits. It wouldn't even help to inhibit quit here - we just process pending signals in Markus' scenario. martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 03:08:01 GMT) Full text and rfc822 format available.Message #23 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 04:07:42 +0100
martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> writes: >> I don't see where in delete_frame we call maybe_quit, > > It's before on line 3619 ... > >> so it's hard for >> me to know whether it's before or after we set its terminal to zero. > > ... which is after on line 3656 of frame.c. > >> If after, testing FRAME_LIVE_P in expose_frame will fix this. If not, >> we need to understand where and how maybe_quit is being called, and >> prevent that. >> >> I don't think I follow you when you talk about Fdelq. Are you saying >> that it's where we call maybe_quit? > > Yes. delete_frame has this block > > block_input (); > Vframe_list = Fdelq (frame, Vframe_list); > unblock_input (); > > and IIRC we blocked input here because we had a similar problem > already. That was bug#74902, and it is identical to this one, AFAICT. > But Fdelq runs FOR_EACH_TAIL (tail) which is defined as > > FOR_EACH_TAIL_INTERNAL (tail, circular_list (tail), true) > > where the last argument is CHECK_QUIT and FOR_EACH_TAIL_INTERNAL has > > || ((check_quit) ? maybe_quit () : (void) 0, 0 < --li.n) \ > > so the frame to be deleted remains on the frame list if this really > quits. It wouldn't even help to inhibit quit here - we just process > pending signals in Markus' scenario. Quitting is not necessary here, pending_signals being true suffices to land in expose_frame. And when it lands there, this is after delete_frame has frame.c: 2776 /* Mark all the windows that used to be on FRAME as deleted, and then 2777 remove the reference to them. */ 2778 delete_all_child_windows (f->root_window); 2779 fset_root_window (f, Qnil); 2780 2781 block_input (); 2782 Vframe_list = Fdelq (frame, Vframe_list); I'd remove the block_input/unblock_input because it cannot help here. Alas, FRAME_LIVE_P in expose_frame won't work either because that checks frame::terminal and that is set to NULL too late in delete_frame. frame.c: 2818 terminal = FRAME_TERMINAL (f); 2819 f->terminal = 0; /* Now the frame is dead. */ One could check WINDOWP (f->root_window) in expose_frame, or maybe in expose_window_tree. One oculd also change FRAME_LIVE_P to check more things. Or one could SET_FRAME_GARBAGED in delete_frame which makes expose_frame return early. Maybe that's the best option, it's all pretty ugly already.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 05:28:02 GMT) Full text and rfc822 format available.Message #26 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 06:27:45 +0100
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" <bug-gnu-emacs <at> gnu.org> writes: > >>> I don't see where in delete_frame we call maybe_quit, >> >> It's before on line 3619 ... >> >>> so it's hard for >>> me to know whether it's before or after we set its terminal to zero. >> >> ... which is after on line 3656 of frame.c. >> >>> If after, testing FRAME_LIVE_P in expose_frame will fix this. If not, >>> we need to understand where and how maybe_quit is being called, and >>> prevent that. >>> >>> I don't think I follow you when you talk about Fdelq. Are you saying >>> that it's where we call maybe_quit? >> >> Yes. delete_frame has this block >> >> block_input (); >> Vframe_list = Fdelq (frame, Vframe_list); >> unblock_input (); >> >> and IIRC we blocked input here because we had a similar problem >> already. > > That was bug#74902, and it is identical to this one, AFAICT. > >> But Fdelq runs FOR_EACH_TAIL (tail) which is defined as >> >> FOR_EACH_TAIL_INTERNAL (tail, circular_list (tail), true) >> >> where the last argument is CHECK_QUIT and FOR_EACH_TAIL_INTERNAL has >> >> || ((check_quit) ? maybe_quit () : (void) 0, 0 < --li.n) \ >> >> so the frame to be deleted remains on the frame list if this really >> quits. It wouldn't even help to inhibit quit here - we just process >> pending signals in Markus' scenario. > > Quitting is not necessary here, pending_signals being true suffices to > land in expose_frame. And when it lands there, this is after > delete_frame has > > frame.c: > 2776 /* Mark all the windows that used to be on FRAME as deleted, and then > 2777 remove the reference to them. */ > 2778 delete_all_child_windows (f->root_window); > 2779 fset_root_window (f, Qnil); > 2780 > 2781 block_input (); > 2782 Vframe_list = Fdelq (frame, Vframe_list); > > I'd remove the block_input/unblock_input because it cannot help here. > Alas, FRAME_LIVE_P in expose_frame won't work either because that checks > frame::terminal and that is set to NULL too late in delete_frame. > > frame.c: > 2818 terminal = FRAME_TERMINAL (f); > 2819 f->terminal = 0; /* Now the frame is dead. */ > > One could check WINDOWP (f->root_window) in expose_frame, or maybe in > expose_window_tree. One oculd also change FRAME_LIVE_P to check more > things. Or one could SET_FRAME_GARBAGED in delete_frame which makes > expose_frame return early. Maybe that's the best option, it's all pretty > ugly already. BTW, looking at other uses of Fdelq, I suspect that there quite some places that would rather not quit.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 06:14:01 GMT) Full text and rfc822 format available.Message #29 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 08:13:30 +0200
> Date: Sun, 4 Jan 2026 00:08:34 +0100
> Cc: triska <at> metalevel.at, luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > I don't see where in delete_frame we call maybe_quit,
>
> It's before on line 3619 ...
>
> > so it's hard for
> > me to know whether it's before or after we set its terminal to zero.
>
> ... which is after on line 3656 of frame.c.
In what version of frame.c do you see these line numbers? The OP used
Emacs 30.2, and the lines you cite don't correspond to what I see
there. They also don't correspond to frame.c on the current master or
on the emacs-30 release branch. So I'm confused.
> > If after, testing FRAME_LIVE_P in expose_frame will fix this. If not,
> > we need to understand where and how maybe_quit is being called, and
> > prevent that.
> >
> > I don't think I follow you when you talk about Fdelq. Are you saying
> > that it's where we call maybe_quit?
>
> Yes. delete_frame has this block
>
> block_input ();
> Vframe_list = Fdelq (frame, Vframe_list);
> unblock_input ();
>
> and IIRC we blocked input here because we had a similar problem already.
> But Fdelq runs FOR_EACH_TAIL (tail) which is defined as
>
> FOR_EACH_TAIL_INTERNAL (tail, circular_list (tail), true)
>
> where the last argument is CHECK_QUIT and FOR_EACH_TAIL_INTERNAL has
>
> || ((check_quit) ? maybe_quit () : (void) 0, 0 < --li.n) \
>
> so the frame to be deleted remains on the frame list if this really
> quits. It wouldn't even help to inhibit quit here - we just process
> pending signals in Markus' scenario.
So what do you suggest we do instead? Check f->glyphs_initialized_p
in expose_frame and return immediately if not?
Another idea, by looking at this code from delete_frame:
/* Mark all the windows that used to be on FRAME as deleted, and then
remove the reference to them. */
delete_all_child_windows (f->root_window);
fset_root_window (f, Qnil); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
block_input ();
Vframe_list = Fdelq (frame, Vframe_list);
unblock_input ();
SET_FRAME_VISIBLE (f, false);
So then, when expose_frame does this:
redisplay_trace ("expose_frame (%d, %d, %u, %u)\n",
r.x, r.y, r.width, r.height);
mouse_face_overwritten_p = expose_window_tree (XWINDOW (f->root_window), &r);
it should first check that f->root_window is a window and not nil, and
if it's nil, return right there and then. This should fix this
specific problem, since that's exactly what happened there: we called
expose_window_tree with a window that is not a window.
Thoughts?
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 06:24:01 GMT) Full text and rfc822 format available.Message #32 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 08:23:30 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Cc: Eli Zaretskii <eliz <at> gnu.org>, luangruo <at> yahoo.com, > 80120 <at> debbugs.gnu.org, triska <at> metalevel.at > Date: Sun, 04 Jan 2026 06:27:45 +0100 > > BTW, looking at other uses of Fdelq, I suspect that there quite some > places that would rather not quit. Examples? And what do you suggest doing instead of calling Fdelq in this cases?
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 06:39:02 GMT) Full text and rfc822 format available.Message #35 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 07:38:27 +0100
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, luangruo <at> yahoo.com, >> 80120 <at> debbugs.gnu.org, triska <at> metalevel.at >> Date: Sun, 04 Jan 2026 06:27:45 +0100 >> >> BTW, looking at other uses of Fdelq, I suspect that there quite some >> places that would rather not quit. > > Examples? buffer.c: 2218 Vbuffer_alist = Fdelq (aelt, Vbuffer_alist); frame.c: 3662 fset_buffer_list 3663 (XFRAME (frame), Fdelq (buffer, XFRAME (frame)->buffer_list)); All uses would have to be checked, IMO. > And what do you suggest doing instead of calling Fdelq in this cases? Write a delq variant that doesn't call maybe_quit?
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 07:09:02 GMT) Full text and rfc822 format available.Message #38 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 09:08:26 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Cc: rudalics <at> gmx.at, luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, > triska <at> metalevel.at > Date: Sun, 04 Jan 2026 07:38:27 +0100 > > Eli Zaretskii <eliz <at> gnu.org> writes: > > >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > >> Cc: Eli Zaretskii <eliz <at> gnu.org>, luangruo <at> yahoo.com, > >> 80120 <at> debbugs.gnu.org, triska <at> metalevel.at > >> Date: Sun, 04 Jan 2026 06:27:45 +0100 > >> > >> BTW, looking at other uses of Fdelq, I suspect that there quite some > >> places that would rather not quit. > > > > Examples? > > buffer.c: > 2218 Vbuffer_alist = Fdelq (aelt, Vbuffer_alist); > > frame.c: > 3662 fset_buffer_list > 3663 (XFRAME (frame), Fdelq (buffer, XFRAME (frame)->buffer_list)); > > All uses would have to be checked, IMO. Why do you think it could be a problem to QUIT in these cases? > > And what do you suggest doing instead of calling Fdelq in this cases? > > Write a delq variant that doesn't call maybe_quit? Just a new optional argument should be enough, I think. But first we need to make sure we indeed need this.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 07:44:02 GMT) Full text and rfc822 format available.Message #41 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 08:43:20 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: rudalics <at> gmx.at, luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org,
>> triska <at> metalevel.at
>> Date: Sun, 04 Jan 2026 07:38:27 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, luangruo <at> yahoo.com,
>> >> 80120 <at> debbugs.gnu.org, triska <at> metalevel.at
>> >> Date: Sun, 04 Jan 2026 06:27:45 +0100
>> >>
>> >> BTW, looking at other uses of Fdelq, I suspect that there quite some
>> >> places that would rather not quit.
>> >
>> > Examples?
>>
>> buffer.c:
>> 2218 Vbuffer_alist = Fdelq (aelt, Vbuffer_alist);
>>
>> frame.c:
>> 3662 fset_buffer_list
>> 3663 (XFRAME (frame), Fdelq (buffer, XFRAME (frame)->buffer_list));
>>
>> All uses would have to be checked, IMO.
>
> Why do you think it could be a problem to QUIT in these cases?
The first one could acutally be okay, I think. It is
buffer.c:
2203 void
2204 record_buffer (Lisp_Object buffer)
2205 {
2206 Lisp_Object aelt, aelt_cons, tem;
2207 register struct frame *f = XFRAME (selected_frame);
2208
2209 CHECK_BUFFER (buffer);
2210
2211 /* Update Vbuffer_alist (we know that it has an entry for BUFFER).
2212 Don't allow quitting since this might leave the buffer list in an
2213 inconsistent state. */
2214 tem = Vinhibit_quit;
2215 Vinhibit_quit = Qt;
2216 aelt = Frassq (buffer, Vbuffer_alist);
2217 aelt_cons = Fmemq (aelt, Vbuffer_alist);
2218 Vbuffer_alist = Fdelq (aelt, Vbuffer_alist);
and sets Vinhibit_quit, which means that maybe_quit, via probably_quit
and so on, and when pending_signals, only lands in goggle_input and so
on. Hard to tell if that can make problems, but at least it doesn't
quit. I'd replace the Fdelq anyway. A circularity check for
Vbuffer_alist is not really needed, IMO.
The second one is
frame.c:
3655 void
3656 frames_discard_buffer (Lisp_Object buffer)
3657 {
3658 Lisp_Object frame, tail;
3659
3660 FOR_EACH_FRAME (tail, frame)
3661 {
3662 fset_buffer_list
3663 (XFRAME (frame), Fdelq (buffer, XFRAME (frame)->buffer_list));
3664 fset_buried_buffer_list
3665 (XFRAME (frame), Fdelq (buffer, XFRAME (frame)->buried_buffer_list));
3666 }
3667 }
This function is called from Fkill_buffer
buffer.c:
193 /* These may run Lisp code and into infinite loops (if someone
194 insisted on circular lists) so allow quitting here. */
195 frames_discard_buffer (buffer);
196
197 clear_charpos_cache (b);
198
199 tem = Vinhibit_quit;
200 Vinhibit_quit = Qt;
and here, Vinhibit_quit is not set, and quitting here can leave the
killed buffer in lists of some frames.
I didn't check the other uses of Fdelq, because these two made me think
using Fdelq is kind of "dangerous" or how one wants to put it. At least
nowadays, don't know when Fdelq changed to check for quit and so on.
>> > And what do you suggest doing instead of calling Fdelq in this cases?
>>
>> Write a delq variant that doesn't call maybe_quit?
>
> Just a new optional argument should be enough, I think.
OTOH, it could invite Lisp programmers to use it, which they probably
shouldn't :-).
>
> But first we need to make sure we indeed need this.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 09:16:02 GMT) Full text and rfc822 format available.Message #44 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 11:15:39 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Cc: rudalics <at> gmx.at, luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, > triska <at> metalevel.at > Date: Sun, 04 Jan 2026 08:43:20 +0100 > > This function is called from Fkill_buffer > > buffer.c: > 193 /* These may run Lisp code and into infinite loops (if someone > 194 insisted on circular lists) so allow quitting here. */ > 195 frames_discard_buffer (buffer); > 196 > 197 clear_charpos_cache (b); > 198 > 199 tem = Vinhibit_quit; > 200 Vinhibit_quit = Qt; > > and here, Vinhibit_quit is not set, and quitting here can leave the > killed buffer in lists of some frames. But the comment says why we allow quitting there, I think? > >> > And what do you suggest doing instead of calling Fdelq in this cases? > >> > >> Write a delq variant that doesn't call maybe_quit? > > > > Just a new optional argument should be enough, I think. > > OTOH, it could invite Lisp programmers to use it, which they probably > shouldn't :-). To their own peril.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 09:20:02 GMT) Full text and rfc822 format available.Message #47 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 10:19:20 +0100
> One could check WINDOWP (f->root_window) in expose_frame, or maybe in > expose_window_tree. One oculd also change FRAME_LIVE_P to check more > things. Or one could SET_FRAME_GARBAGED in delete_frame which makes > expose_frame return early. Maybe that's the best option, it's all pretty > ugly already. Neither of these would work. Many parts of the window code invariably assume that a frame's root window is non-nil. We'd crash sooner or later there. martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 09:20:03 GMT) Full text and rfc822 format available.Message #50 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 10:19:39 +0100
>> It's before on line 3619 ...
>>
>> > so it's hard for
>> > me to know whether it's before or after we set its terminal to zero.
>>
>> ... which is after on line 3656 of frame.c.
>
> In what version of frame.c do you see these line numbers? The OP used
> Emacs 30.2, and the lines you cite don't correspond to what I see
> there. They also don't correspond to frame.c on the current master or
> on the emacs-30 release branch. So I'm confused.
These are the line numbers in master's frame.c that cause the corruption
of the frame list (line 3619) and where the frame's terminal is set to
zero (line 3656).
> So what do you suggest we do instead? Check f->glyphs_initialized_p
> in expose_frame and return immediately if not?
No. Once we've set its root window to nil we cannot keep that frame in
Vframe_list. If we do, Emacs may crash anywhere.
> Another idea, by looking at this code from delete_frame:
>
> /* Mark all the windows that used to be on FRAME as deleted, and then
> remove the reference to them. */
> delete_all_child_windows (f->root_window);
> fset_root_window (f, Qnil); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> block_input ();
> Vframe_list = Fdelq (frame, Vframe_list);
> unblock_input ();
> SET_FRAME_VISIBLE (f, false);
>
> So then, when expose_frame does this:
>
> redisplay_trace ("expose_frame (%d, %d, %u, %u)\n",
> r.x, r.y, r.width, r.height);
> mouse_face_overwritten_p = expose_window_tree (XWINDOW (f->root_window), &r);
>
> it should first check that f->root_window is a window and not nil, and
> if it's nil, return right there and then. This should fix this
> specific problem, since that's exactly what happened there: we called
> expose_window_tree with a window that is not a window.
The only thing we could try is to move the
/* Mark all the windows that used to be on FRAME as deleted, and then
remove the reference to them. */
delete_all_child_windows (f->root_window);
fset_root_window (f, Qnil);
after
block_input ();
Vframe_list = Fdelq (frame, Vframe_list);
unblock_input ();
martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 09:21:02 GMT) Full text and rfc822 format available.Message #53 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 10:19:58 +0100
> The second one is
>
> frame.c:
> 3655 void
> 3656 frames_discard_buffer (Lisp_Object buffer)
> 3657 {
> 3658 Lisp_Object frame, tail;
> 3659
> 3660 FOR_EACH_FRAME (tail, frame)
> 3661 {
> 3662 fset_buffer_list
> 3663 (XFRAME (frame), Fdelq (buffer, XFRAME (frame)->buffer_list));
> 3664 fset_buried_buffer_list
> 3665 (XFRAME (frame), Fdelq (buffer, XFRAME (frame)->buried_buffer_list));
> 3666 }
> 3667 }
>
> This function is called from Fkill_buffer
>
> buffer.c:
> 193 /* These may run Lisp code and into infinite loops (if someone
> 194 insisted on circular lists) so allow quitting here. */
> 195 frames_discard_buffer (buffer);
> 196
> 197 clear_charpos_cache (b);
> 198
> 199 tem = Vinhibit_quit;
> 200 Vinhibit_quit = Qt;
>
> and here, Vinhibit_quit is not set, and quitting here can leave the
> killed buffer in lists of some frames.
Just that we cannot do it in fset_buffer_list because users can set a
frame's buffer list via the 'buffer-list' parameter.
>> Just a new optional argument should be enough, I think.
>
> OTOH, it could invite Lisp programmers to use it, which they probably
> shouldn't :-).
It could invite C programmers to use it where they probably shouldn't.
martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 09:34:02 GMT) Full text and rfc822 format available.Message #56 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 10:33:53 +0100
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> >> Cc: rudalics <at> gmx.at, luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, >> triska <at> metalevel.at >> Date: Sun, 04 Jan 2026 08:43:20 +0100 >> >> This function is called from Fkill_buffer >> >> buffer.c: >> 193 /* These may run Lisp code and into infinite loops (if someone >> 194 insisted on circular lists) so allow quitting here. */ >> 195 frames_discard_buffer (buffer); >> 196 >> 197 clear_charpos_cache (b); >> 198 >> 199 tem = Vinhibit_quit; >> 200 Vinhibit_quit = Qt; >> >> and here, Vinhibit_quit is not set, and quitting here can leave the >> killed buffer in lists of some frames. > > But the comment says why we allow quitting there, I think? I don't understand the comment. frames_discard_buffer and clear_charpos_cache don't run Lisp, AFAICT.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 09:47:02 GMT) Full text and rfc822 format available.Message #59 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 10:46:44 +0100
martin rudalics <rudalics <at> gmx.at> writes:
>> The second one is
>>
>> frame.c:
>> 3655 void
>> 3656 frames_discard_buffer (Lisp_Object buffer)
>> 3657 {
>> 3658 Lisp_Object frame, tail;
>> 3659
>> 3660 FOR_EACH_FRAME (tail, frame)
>> 3661 {
>> 3662 fset_buffer_list
>> 3663 (XFRAME (frame), Fdelq (buffer, XFRAME (frame)->buffer_list));
>> 3664 fset_buried_buffer_list
>> 3665 (XFRAME (frame), Fdelq (buffer, XFRAME (frame)->buried_buffer_list));
>> 3666 }
>> 3667 }
>>
>> This function is called from Fkill_buffer
>>
>> buffer.c:
>> 193 /* These may run Lisp code and into infinite loops (if someone
>> 194 insisted on circular lists) so allow quitting here. */
>> 195 frames_discard_buffer (buffer);
>> 196
>> 197 clear_charpos_cache (b);
>> 198
>> 199 tem = Vinhibit_quit;
>> 200 Vinhibit_quit = Qt;
>>
>> and here, Vinhibit_quit is not set, and quitting here can leave the
>> killed buffer in lists of some frames.
>
> Just that we cannot do it in fset_buffer_list because users can set a
> frame's buffer list via the 'buffer-list' parameter.
I'm afraid I don't understand. Fdelq uses FOR_EACH_TAIL, which signals
Qcircular_list, independent of Vinhibit_quit.
>
>>> Just a new optional argument should be enough, I think.
>>
>> OTOH, it could invite Lisp programmers to use it, which they probably
>> shouldn't :-).
>
> It could invite C programmers to use it where they probably shouldn't.
And that too, yes :-).
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 10:13:01 GMT) Full text and rfc822 format available.Message #62 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 12:12:06 +0200
> Date: Sun, 4 Jan 2026 10:19:39 +0100
> Cc: triska <at> metalevel.at, luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> >> It's before on line 3619 ...
> >>
> >> > so it's hard for
> >> > me to know whether it's before or after we set its terminal to zero.
> >>
> >> ... which is after on line 3656 of frame.c.
> >
> > In what version of frame.c do you see these line numbers? The OP used
> > Emacs 30.2, and the lines you cite don't correspond to what I see
> > there. They also don't correspond to frame.c on the current master or
> > on the emacs-30 release branch. So I'm confused.
>
> These are the line numbers in master's frame.c that cause the corruption
> of the frame list (line 3619) and where the frame's terminal is set to
> zero (line 3656).
I guess you have some local changes, because for me, these are lines
2782 and 2819, respectively.
> > So what do you suggest we do instead? Check f->glyphs_initialized_p
> > in expose_frame and return immediately if not?
>
> No. Once we've set its root window to nil we cannot keep that frame in
> Vframe_list. If we do, Emacs may crash anywhere.
Only for asynchronous accesses to frames, such as in this case. Some
part of the body of delete_frame is in effect a critical section, and
we cannot allow any access to frames while it runs. Here we have an
expose event being processed during this critical-section code, and we
need to prevent that.
> > Another idea, by looking at this code from delete_frame:
> >
> > /* Mark all the windows that used to be on FRAME as deleted, and then
> > remove the reference to them. */
> > delete_all_child_windows (f->root_window);
> > fset_root_window (f, Qnil); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >
> > block_input ();
> > Vframe_list = Fdelq (frame, Vframe_list);
> > unblock_input ();
> > SET_FRAME_VISIBLE (f, false);
> >
> > So then, when expose_frame does this:
> >
> > redisplay_trace ("expose_frame (%d, %d, %u, %u)\n",
> > r.x, r.y, r.width, r.height);
> > mouse_face_overwritten_p = expose_window_tree (XWINDOW (f->root_window), &r);
> >
> > it should first check that f->root_window is a window and not nil, and
> > if it's nil, return right there and then. This should fix this
> > specific problem, since that's exactly what happened there: we called
> > expose_window_tree with a window that is not a window.
>
> The only thing we could try is to move the
>
> /* Mark all the windows that used to be on FRAME as deleted, and then
> remove the reference to them. */
> delete_all_child_windows (f->root_window);
> fset_root_window (f, Qnil);
>
> after
>
> block_input ();
> Vframe_list = Fdelq (frame, Vframe_list);
> unblock_input ();
That's scary, IMO. I prefer simpler solutions, certainly for such
obscure situations.
Why is it a problem to test f->glyphs_initialized_p, and avoid doing
anything with a frame where that is false? We could do it in every
place where a frame is accessed, and delete_frame resets this member
right at its beginning. Quite a few places already do look at that
flag. This is IMO better than relying of Vframe_list be always 110%
clean, because we will never be able to ensure that, what with all the
hooks we have today in C code, and the plethora of places in C code
where we modify Vframe_list. Being able to QUIT from a prolonged
operation is essential for Emacs, so we will be unable to inhibit that
in all cases anyway.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 10:28:02 GMT) Full text and rfc822 format available.Message #65 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 11:27:08 +0100
>>> This function is called from Fkill_buffer >>> >>> buffer.c: >>> 193 /* These may run Lisp code and into infinite loops (if someone >>> 194 insisted on circular lists) so allow quitting here. */ >>> 195 frames_discard_buffer (buffer); >>> 196 >>> 197 clear_charpos_cache (b); >>> 198 >>> 199 tem = Vinhibit_quit; >>> 200 Vinhibit_quit = Qt; >>> >>> and here, Vinhibit_quit is not set, and quitting here can leave the >>> killed buffer in lists of some frames. >> >> But the comment says why we allow quitting there, I think? > > I don't understand the comment. frames_discard_buffer and > clear_charpos_cache don't run Lisp, AFAICT. fset_buffer_list may be run from Lisp and make a circular buffer list if the user was not careful. If we now run frames_discard_buffer on such a list it may loop forever. martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 10:28:03 GMT) Full text and rfc822 format available.Message #68 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 11:27:16 +0100
>> Just that we cannot do it in fset_buffer_list because users can set a >> frame's buffer list via the 'buffer-list' parameter. > > I'm afraid I don't understand. Fdelq uses FOR_EACH_TAIL, which signals > Qcircular_list, independent of Vinhibit_quit. Right. I meant if we used a version that doesn't signal Qcircular_list. martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 10:29:01 GMT) Full text and rfc822 format available.Message #71 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 11:27:50 +0100
>> These are the line numbers in master's frame.c that cause the corruption >> of the frame list (line 3619) and where the frame's terminal is set to >> zero (line 3656). > > I guess you have some local changes, because for me, these are lines > 2782 and 2819, respectively. You're right. I must have used another version. Sorry for that. >> No. Once we've set its root window to nil we cannot keep that frame in >> Vframe_list. If we do, Emacs may crash anywhere. > > Only for asynchronous accesses to frames, such as in this case. Some > part of the body of delete_frame is in effect a critical section, and > we cannot allow any access to frames while it runs. Here we have an > expose event being processed during this critical-section code, and we > need to prevent that. But an expose event can run arbitrary code IIUC. >> The only thing we could try is to move the >> >> /* Mark all the windows that used to be on FRAME as deleted, and then >> remove the reference to them. */ >> delete_all_child_windows (f->root_window); >> fset_root_window (f, Qnil); >> >> after >> >> block_input (); >> Vframe_list = Fdelq (frame, Vframe_list); >> unblock_input (); > > That's scary, IMO. I prefer simpler solutions, certainly for such > obscure situations. Agreed. > Why is it a problem to test f->glyphs_initialized_p, and avoid doing > anything with a frame where that is false? We could do it in every > place where a frame is accessed, and delete_frame resets this member > right at its beginning. Quite a few places already do look at that > flag. This is IMO better than relying of Vframe_list be always 110% > clean, because we will never be able to ensure that, what with all the > hooks we have today in C code, and the plethora of places in C code > where we modify Vframe_list. Being able to QUIT from a prolonged > operation is essential for Emacs, so we will be unable to inhibit that > in all cases anyway. Having an officially live frame whose root window is nil means we can forgot about any part of the window code DTRT. martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 10:37:01 GMT) Full text and rfc822 format available.Message #74 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 11:36:02 +0100
martin rudalics <rudalics <at> gmx.at> writes: >>> Just that we cannot do it in fset_buffer_list because users can set a >>> frame's buffer list via the 'buffer-list' parameter. >> >> I'm afraid I don't understand. Fdelq uses FOR_EACH_TAIL, which signals >> Qcircular_list, independent of Vinhibit_quit. > > Right. I meant if we used a version that doesn't signal Qcircular_list. > > martin So we'd meed a Fdelq variant which just doesn't check quit but still does the circularity check. Basically Fdelq with FOR_EACH_TAIL_INTERNAL (tail, circular_list (tail), false) instead of FOR_EACH_TAIL.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 10:43:02 GMT) Full text and rfc822 format available.Message #77 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Markus Triska <triska <at> metalevel.at> To: martin rudalics <rudalics <at> gmx.at> Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 11:42:48 +0100
martin rudalics <rudalics <at> gmx.at> writes: >> Does anyone have any idea what is going on here? > > #10 process_pending_signals () at keyboard.c:8172 > #11 0x000055555573fd6d in probably_quit () at eval.c:1794 > #12 0x0000555555747a6d in maybe_quit () at Thank you a lot for looking into this! Is there a way to systematically elicit this situation with Elisp code? I'm currently trying to reproduce the crash, and would greatly appreciate any help with this.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 10:57:02 GMT) Full text and rfc822 format available.Message #80 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 11:56:29 +0100
martin rudalics <rudalics <at> gmx.at> writes: >>> These are the line numbers in master's frame.c that cause the corruption >>> of the frame list (line 3619) and where the frame's terminal is set to >>> zero (line 3656). >> >> I guess you have some local changes, because for me, these are lines >> 2782 and 2819, respectively. > > You're right. I must have used another version. Sorry for that. > >>> No. Once we've set its root window to nil we cannot keep that frame in >>> Vframe_list. If we do, Emacs may crash anywhere. >> >> Only for asynchronous accesses to frames, such as in this case. Some >> part of the body of delete_frame is in effect a critical section, and >> we cannot allow any access to frames while it runs. Here we have an >> expose event being processed during this critical-section code, and we >> need to prevent that. > > But an expose event can run arbitrary code IIUC. > >>> The only thing we could try is to move the >>> >>> /* Mark all the windows that used to be on FRAME as deleted, and then >>> remove the reference to them. */ >>> delete_all_child_windows (f->root_window); >>> fset_root_window (f, Qnil); >>> >>> after >>> >>> block_input (); >>> Vframe_list = Fdelq (frame, Vframe_list); >>> unblock_input (); >> >> That's scary, IMO. I prefer simpler solutions, certainly for such >> obscure situations. > > Agreed. > >> Why is it a problem to test f->glyphs_initialized_p, and avoid doing >> anything with a frame where that is false? We could do it in every >> place where a frame is accessed, and delete_frame resets this member >> right at its beginning. Quite a few places already do look at that >> flag. This is IMO better than relying of Vframe_list be always 110% >> clean, because we will never be able to ensure that, what with all the >> hooks we have today in C code, and the plethora of places in C code >> where we modify Vframe_list. Being able to QUIT from a prolonged >> operation is essential for Emacs, so we will be unable to inhibit that >> in all cases anyway. > > Having an officially live frame whose root window is nil means we can > forgot about any part of the window code DTRT. > > martin +1 The root of the problem, from where I sit, is that a lot of functions (Fdelq, Fassq, everything using FOR_EACH_TAIL) implicitly handle input events via calling maybe_quit. And one cannot even find out without digging in the outgoing call hierarchy. But it is what it is, I guess.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 11:08:02 GMT) Full text and rfc822 format available.Message #83 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 13:06:45 +0200
> Date: Sun, 4 Jan 2026 11:27:50 +0100 > Cc: triska <at> metalevel.at, luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org > From: martin rudalics <rudalics <at> gmx.at> > > > Why is it a problem to test f->glyphs_initialized_p, and avoid doing > > anything with a frame where that is false? We could do it in every > > place where a frame is accessed, and delete_frame resets this member > > right at its beginning. Quite a few places already do look at that > > flag. This is IMO better than relying of Vframe_list be always 110% > > clean, because we will never be able to ensure that, what with all the > > hooks we have today in C code, and the plethora of places in C code > > where we modify Vframe_list. Being able to QUIT from a prolonged > > operation is essential for Emacs, so we will be unable to inhibit that > > in all cases anyway. > > Having an officially live frame whose root window is nil means we can > forgot about any part of the window code DTRT. Then how about adding the glyphs_initialized_p test to FRAME_LIVE_P?
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 11:08:03 GMT) Full text and rfc822 format available.Message #86 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Markus Triska <triska <at> metalevel.at> Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 12:07:36 +0100
> Thank you a lot for looking into this! Is there a way to systematically > elicit this situation with Elisp code? I'm currently trying to reproduce > the crash, and would greatly appreciate any help with this. No hope at all. It's a quite grave internal bug that can be resolved only at the C level. martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 11:12:02 GMT) Full text and rfc822 format available.Message #89 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 13:11:11 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Cc: Eli Zaretskii <eliz <at> gnu.org>, luangruo <at> yahoo.com, > 80120 <at> debbugs.gnu.org, triska <at> metalevel.at > Date: Sun, 04 Jan 2026 11:56:29 +0100 > > The root of the problem, from where I sit, is that a lot of functions > (Fdelq, Fassq, everything using FOR_EACH_TAIL) implicitly handle input > events via calling maybe_quit. And one cannot even find out without > digging in the outgoing call hierarchy. But it is what it is, I guess. It is perfectly fine for these functions to handle input events, in general. What we are saying here is that we would perhaps like to prevent that when these functions are called to manipulate some data structures crucial to the Emacs internals. But that is just a very specific use of these functions, whose main purpose is different. So one way out of this is to have a special set of C functions to manipulate Vframe_list and other internal variables, and let those refrain from processing any input events.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 11:16:02 GMT) Full text and rfc822 format available.Message #92 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org>, Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 12:15:04 +0100
>> The root of the problem, from where I sit, is that a lot of functions >> (Fdelq, Fassq, everything using FOR_EACH_TAIL) implicitly handle input >> events via calling maybe_quit. And one cannot even find out without >> digging in the outgoing call hierarchy. But it is what it is, I guess. > > It is perfectly fine for these functions to handle input events, in > general. What we are saying here is that we would perhaps like to > prevent that when these functions are called to manipulate some > data structures crucial to the Emacs internals. But that is just a > very specific use of these functions, whose main purpose is different. > > So one way out of this is to have a special set of C functions to > manipulate Vframe_list and other internal variables, and let those > refrain from processing any input events. We already have assq_no_quit. So let's add delq_no_quit. martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 11:20:02 GMT) Full text and rfc822 format available.Message #95 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 4 Jan 2026 12:19:31 +0100
> So we'd meed a Fdelq variant which just doesn't check quit but still > does the circularity check. Basically Fdelq with > > FOR_EACH_TAIL_INTERNAL (tail, circular_list (tail), false) > > instead of FOR_EACH_TAIL. FOR_EACH_TAIL_SAFE? martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 11:33:01 GMT) Full text and rfc822 format available.Message #98 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: gerd.moellmann <at> gmail.com, luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 13:32:03 +0200
> Date: Sun, 4 Jan 2026 12:15:04 +0100 > Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at > From: martin rudalics <rudalics <at> gmx.at> > > >> The root of the problem, from where I sit, is that a lot of functions > >> (Fdelq, Fassq, everything using FOR_EACH_TAIL) implicitly handle input > >> events via calling maybe_quit. And one cannot even find out without > >> digging in the outgoing call hierarchy. But it is what it is, I guess. > > > > It is perfectly fine for these functions to handle input events, in > > general. What we are saying here is that we would perhaps like to > > prevent that when these functions are called to manipulate some > > data structures crucial to the Emacs internals. But that is just a > > very specific use of these functions, whose main purpose is different. > > > > So one way out of this is to have a special set of C functions to > > manipulate Vframe_list and other internal variables, and let those > > refrain from processing any input events. > > We already have assq_no_quit. So let's add delq_no_quit. No objection here. But that is just part of fixing this and similar bugs. The other party is that we should exclude frames being deleted from any significant processing.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 11:37:01 GMT) Full text and rfc822 format available.Message #101 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 12:36:47 +0100
martin rudalics <rudalics <at> gmx.at> writes: >> So we'd meed a Fdelq variant which just doesn't check quit but still >> does the circularity check. Basically Fdelq with >> >> FOR_EACH_TAIL_INTERNAL (tail, circular_list (tail), false) >> >> instead of FOR_EACH_TAIL. > > FOR_EACH_TAIL_SAFE? > > martin That wouldn't signal Qcircular_list: #define FOR_EACH_TAIL_SAFE(tail) \ FOR_EACH_TAIL_INTERNAL (tail, (void) ((tail) = Qnil), false)
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 04 Jan 2026 11:39:02 GMT) Full text and rfc822 format available.Message #104 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 04 Jan 2026 12:38:50 +0100
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > martin rudalics <rudalics <at> gmx.at> writes: > >>> So we'd meed a Fdelq variant which just doesn't check quit but still >>> does the circularity check. Basically Fdelq with >>> >>> FOR_EACH_TAIL_INTERNAL (tail, circular_list (tail), false) >>> >>> instead of FOR_EACH_TAIL. >> >> FOR_EACH_TAIL_SAFE? >> >> martin > > That wouldn't signal Qcircular_list: > > #define FOR_EACH_TAIL_SAFE(tail) \ > FOR_EACH_TAIL_INTERNAL (tail, (void) ((tail) = Qnil), false) So it depends, if one wants that or not.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Tue, 06 Jan 2026 18:46:02 GMT) Full text and rfc822 format available.Message #107 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Markus Triska <triska <at> metalevel.at> To: martin rudalics <rudalics <at> gmx.at> Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Tue, 06 Jan 2026 19:45:34 +0100
martin rudalics <rudalics <at> gmx.at> writes: > No hope at all. It's a quite grave internal bug that can be resolved > only at the C level. Is there really nothing I can do to trigger it from Elisp, or to at least make its appearance more likely? Not resolve it, but trigger it! I tried repeatedly creating and deleting a frame with Elisp, and it seems to work reliably. But on the other hand, sometimes (in other situations) I do see the mentioned crash, so there seems to be an issue that arises only in rare situations, and I hope I find a way to produce the crash reliably so that any future solution can be tested easily. Thank you and all the best, Markus
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Wed, 07 Jan 2026 08:46:02 GMT) Full text and rfc822 format available.Message #110 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Markus Triska <triska <at> metalevel.at> Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Wed, 7 Jan 2026 09:45:11 +0100
> Is there really nothing I can do to trigger it from Elisp, or to at > least make its appearance more likely? Not resolve it, but trigger it! > > I tried repeatedly creating and deleting a frame with Elisp, and it > seems to work reliably. But on the other hand, sometimes (in other > situations) I do see the mentioned crash, so there seems to be an issue > that arises only in rare situations, and I hope I find a way to produce > the crash reliably so that any future solution can be tested easily. IIUC the only thing process_pending_signals does is to run timers. So the only way to trigger the crash I see is to set up a loop that continuously creates and deletes frames and put a function on a timer that calls 'redisplay'. Are you using timers extensively? martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Wed, 07 Jan 2026 10:24:02 GMT) Full text and rfc822 format available.Message #113 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Markus Triska <triska <at> metalevel.at> Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Wed, 7 Jan 2026 11:23:25 +0100
[Message part 1 (text/plain, inline)]
> Is there really nothing I can do to trigger it from Elisp, or to at > least make its appearance more likely? Not resolve it, but trigger it! If you can build Emacs try the attached diff. martin
[delq_no_quit.diff (text/x-patch, attachment)]
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Wed, 07 Jan 2026 13:42:02 GMT) Full text and rfc822 format available.Message #116 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Wed, 07 Jan 2026 15:41:19 +0200
> Date: Wed, 7 Jan 2026 09:45:11 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>,
> 80120 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > Is there really nothing I can do to trigger it from Elisp, or to at
> > least make its appearance more likely? Not resolve it, but trigger it!
> >
> > I tried repeatedly creating and deleting a frame with Elisp, and it
> > seems to work reliably. But on the other hand, sometimes (in other
> > situations) I do see the mentioned crash, so there seems to be an issue
> > that arises only in rare situations, and I hope I find a way to produce
> > the crash reliably so that any future solution can be tested easily.
>
> IIUC the only thing process_pending_signals does is to run timers.
No, it does this:
void
process_pending_signals (void)
{
pending_signals = false;
handle_async_input ();
do_pending_atimers ();
}
and handle_async_input calls gobble_input, which reads from the input
queue. So all the X events are received and processed there, and in
particular any Expose events, which cause us to call expose_frame and
its subroutines.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Wed, 07 Jan 2026 20:49:02 GMT) Full text and rfc822 format available.Message #119 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Markus Triska <triska <at> metalevel.at> To: martin rudalics <rudalics <at> gmx.at> Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>, 80120 <at> debbugs.gnu.org Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Wed, 07 Jan 2026 21:48:25 +0100
martin rudalics <rudalics <at> gmx.at> writes: > If you can build Emacs try the attached diff. Thank you a lot, it looks good so far! I will post more if such a crash happens again in the future even with this patch installed. All the best, Markus
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Thu, 08 Jan 2026 09:22:02 GMT) Full text and rfc822 format available.Message #122 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Thu, 8 Jan 2026 10:21:01 +0100
>> IIUC the only thing process_pending_signals does is to run timers.
>
> No, it does this:
>
> void
> process_pending_signals (void)
> {
> pending_signals = false;
> handle_async_input ();
> do_pending_atimers ();
> }
>
> and handle_async_input calls gobble_input, which reads from the input
> queue. So all the X events are received and processed there, and in
> particular any Expose events, which cause us to call expose_frame and
> its subroutines.
I naively thought that gobble_input would do nothing due to the fact
that input is blocked. So this tortoise mechanism does both, check for
circularity and check for the presence of user interrupts - the latter
probably to handle the case where the circularity check fails.
martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sat, 10 Jan 2026 13:12:02 GMT) Full text and rfc822 format available.Message #125 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sat, 10 Jan 2026 15:11:13 +0200
> Date: Wed, 7 Jan 2026 11:23:25 +0100 > Cc: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>, > 80120 <at> debbugs.gnu.org > From: martin rudalics <rudalics <at> gmx.at> > > > Is there really nothing I can do to trigger it from Elisp, or to at > > least make its appearance more likely? Not resolve it, but trigger it! > > If you can build Emacs try the attached diff. Thanks, I think you should install this on master.
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 11 Jan 2026 09:39:02 GMT) Full text and rfc822 format available.Message #128 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 11 Jan 2026 10:38:31 +0100
> Thanks, I think you should install this on master. Installed now (the delq_no_quit part). As for the next potential crash I think we have to peel out the REPLACE_BUFFER_IN_WINDOWS_SAFELY mechanism from window_loop and replace it with a more robust approach. martin
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 11 Jan 2026 11:30:03 GMT) Full text and rfc822 format available.Message #131 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 11 Jan 2026 13:29:35 +0200
> Date: Sun, 11 Jan 2026 10:38:31 +0100 > Cc: triska <at> metalevel.at, luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org > From: martin rudalics <rudalics <at> gmx.at> > > > Thanks, I think you should install this on master. > > Installed now (the delq_no_quit part). As for the next potential crash > I think we have to peel out the REPLACE_BUFFER_IN_WINDOWS_SAFELY > mechanism from window_loop and replace it with a more robust approach. Sorry, I missed that part of the discussion, it seems. Can you point me to the message where that was mentioned?
bug-gnu-emacs <at> gnu.org:bug#80120; Package emacs.
(Sun, 11 Jan 2026 14:03:02 GMT) Full text and rfc822 format available.Message #134 received at 80120 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 80120 <at> debbugs.gnu.org, triska <at> metalevel.at Subject: Re: bug#80120: 30.2; Emacs sometimes crashes in expose_window_tree Date: Sun, 11 Jan 2026 15:02:20 +0100
>> Installed now (the delq_no_quit part). As for the next potential crash >> I think we have to peel out the REPLACE_BUFFER_IN_WINDOWS_SAFELY >> mechanism from window_loop and replace it with a more robust approach. > > Sorry, I missed that part of the discussion, it seems. Can you point > me to the message where that was mentioned? We didn't discuss that yet. Gerd mentioned a few places where Fdelq could cause crashes similar to the one we try to fix here. When I looked around I found that window_loop has a similar problem: There we construct window_list_1 via Fnreverse and Fmemq which, if I'm not mistaken, may call process_pending_signal as well with similar consequences - a dead buffer in a live window. Please check whether my reasoning is correct. Thanks, martin
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.