Subject: Re: bug#76705: 31.0.50; igc: crash

From: Pip Cet <[email-masked]>
Date: Mon, 03 Mar 2025 11:38:01 +0000

Óscar Fuentes via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <[email-masked]> writes:

> Emacs just crashed on a session started more than a week ago, IIRC.
>
> The following backtrace is from the core dump. Sorry for not being more
> helpful.

Can you try generating a full backtrace ("bt full" should work on the
core dump, too)?

> #0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
>     at ./nptl/pthread_kill.c:44
> #1  0x00007f487751de2f in __pthread_kill_internal (threadid=<optimized out>, signo=6)
>     at ./nptl/pthread_kill.c:78
> #2  0x00007f48774c9d02 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
> #3  0x0000556e0ead9d68 in terminate_due_to_signal
>     (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ../../emacs/src/emacs.c:463
> #4  0x0000556e0ed16d73 in set_state (state=IGC_STATE_DEAD) at ../../emacs/src/igc.c:1023
> #5  set_state (state=IGC_STATE_DEAD) at ../../emacs/src/igc.c:1002
> #6  igc_assert_fail (file=<optimized out>, line=<optimized out>, msg=<optimized out>)
>     at ../../emacs/src/igc.c:306
> #7  0x0000556e0edd0c10 in shieldFlushEntries ()

shieldFlushEntries contains several asserts.  Can you disassemble the
function shieldFlushEntries to see which one we hit?
(gdb: "disass/s shieldFlushEntries").

> #8  0x0000556e0edd1b89 in ShieldLeave ()
> #9  0x0000556e0edd1d9e in ArenaLeave ()
> #10 0x0000556e0eddbd31 in mps_ap_fill ()
> #11 0x0000556e0ed164d6 in alloc_impl
>     (size=size@entry=88, type=type@entry=IGC_OBJ_VECTOR, ap=0x7f4868001900) at ../../emacs/src/igc.c:4095
> #12 0x0000556e0ed1afa8 in alloc (size=88, type=IGC_OBJ_VECTOR) at ../../emacs/src/igc.c:4008
> #13 igc_alloc_pseudovector
>     (nwords_mem=nwords_mem@entry=9, nwords_lisp=nwords_lisp@entry=0, nwords_zero=nwords_zero@entry=0, tag=tag@entry=PVEC_HASH_TABLE) at ../../emacs/src/igc.c:4277
> #14 0x0000556e0ec65bae in allocate_pseudovector
>     (memlen=memlen@entry=9, lisplen=lisplen@entry=0, zerolen=zerolen@entry=0, tag=tag@entry=PVEC_HASH_TABLE) at ../../emacs/src/alloc.c:3687
> #15 0x0000556e0ec938d4 in allocate_hash_table () at ../../emacs/src/fns.c:4842
> #16 make_hash_table (test=0x556e0ee7bf80 <hashtest_equal>, size=2, weak=<optimized out>)
>     at ../../emacs/src/fns.c:4897
> #17 0x0000556e0ed2a96a in json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1608
> #18 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
> #19 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0)
>     at ../../emacs/src/json.c:1522
> #20 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554
> #21 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
> #22 0x0000556e0ed2a7fa in json_parse_array (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1454
> #23 json_parse_value (parser=0x7ffd3b15cdd0, c=91) at ../../emacs/src/json.c:1657
> #24 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0)
>     at ../../emacs/src/json.c:1522
> #25 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554
> #26 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
> #27 0x0000556e0ed2a7fa in json_parse_array (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1454
> #28 json_parse_value (parser=0x7ffd3b15cdd0, c=91) at ../../emacs/src/json.c:1657
> #29 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0)
>     at ../../emacs/src/json.c:1522
> #30 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554
> #31 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
> #32 0x0000556e0ed2a7fa in json_parse_array (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1454
> #33 json_parse_value (parser=0x7ffd3b15cdd0, c=91) at ../../emacs/src/json.c:1657
> #34 0x0000556e0ed2a61a in json_parse_object_member_value (parser=0x7ffd3b15cdd0)
>     at ../../emacs/src/json.c:1522
> #35 json_parse_object (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1554
> #36 json_parse_value (parser=0x7ffd3b15cdd0, c=<optimized out>) at ../../emacs/src/json.c:1655
> #37 0x0000556e0ed2aef5 in json_parse (parser=0x7ffd3b15cdd0) at ../../emacs/src/json.c:1705
> #38 Fjson_parse_buffer (nargs=<optimized out>, args=<optimized out>) at ../../emacs/src/json.c:1812
> #39 0x0000556e0ecd9cba in exec_byte_code
>     (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
>     at ../../emacs/src/lisp.h:2290
> #40 0x0000556e0ec8d858 in Ffuncall (nargs=nargs@entry=3, args=0x7ffd3b15d3d0)
>     at ../../emacs/src/eval.c:3115
> #41 0x0000556e0ec8dbe4 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffd3b15d460)
>     at ../../emacs/src/eval.c:2787
> #42 0x0000556e0ec8df63 in apply1 (fn=<optimized out>, arg=<optimized out>) at ../../emacs/src/eval.c:3003
> #43 0x0000556e0ec88fa2 in internal_condition_case_1
>     (bfun=bfun@entry=0x556e0ece67b0 <read_process_output_call>, arg=0x7f4767c4805b, handlers=handlers@entry=0xa8, hfun=hfun@entry=0x556e0ece66f0 <read_process_output_error_handler>) at ../../emacs/src/eval.c:1650
> #44 0x0000556e0ece93a6 in read_and_dispose_of_process_output
>     (p=<optimized out>, chars=0x556e40d23290 ",{\"detail\":\"void (lxw_workbook *, decltype(lxw_workbook::options))\",\"kind\":6,\"name\":\"w\",\"range\":{\"end\":{\"character\":57,\"line\":12784},\"start\":{\"character\":0,\"line\":12784}},\"selectionRange\":{\"end\":{\"cha"..., nbytes=335897, coding=0x556e2eba74b0)

335 KB? That's a lot, so it's likely that the problem was caused in the
json code...  I'll have a look, particularly at xcdr_addr, which is
rarely used in other code.

> In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
>  version 1.18.2) of 2025-02-13 built on zen
> Repository revision: 4b28c41c4f2b43add865f9a8727879cb53dad107

Hmm.  That's a bit older, but I don't think this looks like any of the
bugs that have been fixed since.

Thanks for the report, I'll try stress-testing the JSON code next.

Pip