Subject: bug#76237: 31.0.50; feature/igc: crash #1, 2025-02-12

From: Pip Cet <[email-masked]>
Date: Thu, 13 Feb 2025 11:52:19 +0000

"Oliver Reiter" <[email-masked]> writes:

> Pip Cet <[email-masked]> writes:
>
>> "Oliver Reiter via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <[email-masked]> 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@entry=XIL(0x7fffe881cb35), nargs=nargs@entry=2,
>     arg_vector=arg_vector@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