Package: emacs;
Reported by: Oliver Reiter <oliver.reiter <at> snapdragon.cc>
Date: Wed, 12 Feb 2025 20:21:01 UTC
Severity: normal
Found in version 31.0.50
Done: Pip Cet <pipcet <at> protonmail.com>
Bug is archived. No further changes may be made.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Oliver Reiter <oliver.reiter <at> snapdragon.cc> Cc: bug-gnu-emacs <at> gnu.org, 76237 <at> debbugs.gnu.org Subject: Re: bug#76237: 31.0.50; feature/igc: crash #1, 2025-02-12 Date: Thu, 13 Feb 2025 11:52:19 +0000
"Oliver Reiter" <oliver.reiter <at> snapdragon.cc> writes: > Pip Cet <pipcet <at> protonmail.com> writes: > >> "Oliver Reiter via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes: >> >>> Dear all, >>> >>> crash happened while opening a .org file: >> >> Thanks! This one looks like we might get somewhere with it! >> >>> (gdb) bt >> >> Can you include "bt full" as well? >> > Sure: > > (gdb) bt full > #26 0x000055555570e3cd in Fcons (car=<optimized out>, cdr=<optimized out>) > at /home/reitero/build/sources/emacs/emacs/src/alloc.c:2812 > No locals. > #27 0x0000555555766436 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, > nargs=<optimized out>, args=<optimized out>) > at /home/reitero/build/sources/emacs/emacs/src/bytecode.c:1106 > call_nargs = <optimized out> > arrayval = <optimized out> > arrayval = <optimized out> > res = <optimized out> > res = <optimized out> > res = <optimized out> > res = <optimized out> > handler = <optimized out> > n = <optimized out> > n = <optimized out> > op = <optimized out> > newelt = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > size = <optimized out> > size = <optimized out> > v1 = <optimized out> > --Type <RET> for more, q to quit, c to continue without paging-- > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v1 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > v2 = <optimized out> > targets = <optimized out> > cell = <optimized out> > cell = <optimized out> > newval = <optimized out> > newval = <optimized out> > --Type <RET> for more, q to quit, c to continue without paging-- > template = <optimized out> > call_args = <optimized out> > val = <optimized out> > idxval = <optimized out> > idxval = <optimized out> > count1 = <optimized out> > count1 = <optimized out> > ptr = <optimized out> > ptr = <optimized out> > idx = <optimized out> > idx = <optimized out> > call_fun = <optimized out> > original_fun = <optimized out> > type = <optimized out> > body = <optimized out> > handlers = <optimized out> > quitcounter = 160 '\240' > bc = 0x555555917c18 <main_thread+504> > top = 0x7fffdf3ff670 So the question is whether this "top" pointer may have exceeded the scan limit of our bytecode stack scanning code. Can you try (gdb) p main_thread.s.bc then (gdb) p bc_next_frame (main_thread.s.bc.fp) >> >> The interesting thing is that the segment from 0x7ffffeca46290 to >> 0x7fffeca46318 is small enough to print in its entirety. Can you please >> do that by running >> >> x/17gx 0x7fffeca46290 >> > > (gdb) x/17gx 0x7fffeca46290 > 0x7fffeca46290: 0x0000000504d3d919 0x0000000000000011 > 0x7fffeca462a0: 0xffffffffffffffff 0x0000000000000000 > 0x7fffeca462b0: 0x00007fffe21fe9b0 0x0000000335cd620d > 0x7fffeca462c0: 0x00007fffe2d2c323 0x00007fffe1a059a3 > 0x7fffeca462d0: 0x000000062e03e021 0x4000000021000004 > 0x7fffeca462e0: 0x00007fffe1966f23 0x00007fffe1a0567c > 0x7fffeca462f0: 0x00007fffe1a02eb5 0x000000000000001e > 0x7fffeca46300: 0x0000000340da230d 0x00007fffe1a41d05 > 0x7fffeca46310: 0x00007fffe36a119b So that's a string, followed by a cons cell, followed by a PVEC_CLOSURE. No immediate ideas here. > (gdb) fr 28 > #28 0x000055555572d61c in funcall_lambda (fun=fun <at> entry=XIL(0x7fffe881cb35), nargs=nargs <at> entry=2, > arg_vector=arg_vector <at> entry=0x7fffffffb358) > at /home/reitero/build/sources/emacs/emacs/src/eval.c:3274 > 3274 return exec_byte_code (fun, XFIXNUM (syms_left), nargs, arg_vector); > (gdb) pp fun > Cannot access memory at address 0x555555917ff0 > (gdb) x/32gx 0x7fffe881cb30 > 0x7fffe881cb30: 0x0000000702073621 0x4000000021000005 > 0x7fffe881cb40: 0x000000000000080a 0x00007fffec69dcfc > 0x7fffe881cb50: 0x00007fffeac314d5 0x000000000000002e > 0x7fffe881cb60: 0x00007fffec69dd24 0x0000000500000009 0x00007fffec69dd24 should be the docstring, but it may be a bit hard to print. try p *(struct Lisp_String *)0x00007fffec69dd20, maybe >> Is this reproducible, by any chance? > > Doesn't seem so, I have been opening the same and different .org files > ever since, without a crash. I also tried running the code in a loop, but no crash so far, either. Thanks so far, it does look like it might be unscanned byte code stack, but we'll have to make sure... Pip
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.