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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: bug-gnu-emacs <at> gnu.org, 76237 <at> debbugs.gnu.org,
 Oliver Reiter <oliver.reiter <at> snapdragon.cc>
Subject: Re: bug#76237: 31.0.50; feature/igc: crash #1, 2025-02-12
Date: Wed, 12 Feb 2025 20:50:06 +0000

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

> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at /home/reitero/build/sources/emacs/emacs/src/emacs.c:425
> #1  0x000055555579ef5a in set_state (state=state <at> entry=IGC_STATE_DEAD) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1017
> #2  0x00005555557a0a7b in igc_assert_fail (file=<optimized out>, line=<optimized out>, msg=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/igc.c:306
> #3  0x0000555555835579 in LockClaim ()
> #4  0x0000555555835825 in ArenaEnterLock ()
> #5  0x000055555585f33e in ArenaAccess ()
> #6  0x000055555585f834 in sigHandle ()
> #7  <signal handler called>
> #8  __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:833
> #9  0x000055555586962d in amcSegFix ()
> #10 0x000055555580362d in _mps_fix2 ()
> #11 0x00005555557994a7 in fix_raw (ss=ss <at> entry=0x7fffffffad78, p=p <at> entry=0x7fffffffabf0) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1188
> #12 0x0000555555799563 in fix_string (ss=ss <at> entry=0x7fffffffad78, s=s <at> entry=0x7fffeca46290) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1765
> #13 0x00005555557a0f93 in dflt_scan_obj (ss=ss <at> entry=0x7fffffffad78, base_start=base_start <at> entry=0x7fffeca46290, base_limit=base_limit <at> entry=0x7fffeca46318, closure=closure <at> entry=0x0)
>     at /home/reitero/build/sources/emacs/emacs/src/igc.c:2032
> #14 0x00005555557a1146 in dflt_scanx (ss=ss <at> entry=0x7fffffffad78, base_start=<optimized out>, base_limit=0x7fffeca46318, closure=closure <at> entry=0x0) at /home/reitero/build/sources/emacs/emacs/src/igc.c:2099

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

?

> #15 0x00005555557a1182 in dflt_scan (ss=0x7fffffffad78, base_start=<optimized out>, base_limit=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/igc.c:2110
> #16 0x0000555555834ce5 in amcSegScan ()
> #17 0x0000555555863ec0 in traceScanSegRes ()
> #18 0x00005555558640aa in traceScanSeg ()
> #19 0x0000555555864f06 in TraceAdvance ()
> #20 0x00005555558656cd in TracePoll ()
> #21 0x0000555555865939 in ArenaPoll ()
> #22 0x0000555555865d23 in mps_ap_fill ()
> #23 0x000055555579d572 in alloc_impl (size=size <at> entry=24, type=type <at> entry=IGC_OBJ_CONS, ap=0x7fffe8001900) at /home/reitero/build/sources/emacs/emacs/src/igc.c:4089
> #24 0x000055555579d661 in alloc (size=size <at> entry=24, type=type <at> entry=IGC_OBJ_CONS) at /home/reitero/build/sources/emacs/emacs/src/igc.c:4117
> #25 0x000055555579d682 in igc_make_cons (car=XIL(0x7fffe5e86e6b), cdr=XIL(0x7fffe5e875ab)) at /home/reitero/build/sources/emacs/emacs/src/igc.c:4146
> #26 0x000055555570e3cd in Fcons (car=<optimized out>, cdr=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/alloc.c:2812
> #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

It would be really good to know how much of the byte code stack was in
use at the time.  I thought HORRIBLE_ESTIMATE meant that 1024 words of
stack space were guaranteed for every bytecode object, but I got my
units messed up: it's only 1024 bytes!  And limiting the bytecode reader
to accept only objects which declare less than 128 words of stack space
yields plenty of candidates.

So it would be good to find out which bytecode function was on the stack
here.

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

Can you find out more about fun, maybe?  "pp fun" might work, or "x/32gx
0x7fffe881cb30" for the raw data.

Is this reproducible, by any chance?

Pip

Previous Next

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