Subject: bug#76327: 29.4; random segfaults after switch to tree-sitter

From: Pip Cet <[email-masked]>
Date: Mon, 17 Feb 2025 14:46:52 +0000

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

> On Sun, Feb 16, 2025 at 11:48:52AM +0200, Eli Zaretskii wrote:
>> Please show this symbol:
>>
>>   (gdb) source /path/to/emacs/src/.gdbinit
>>   (gdb) frame 0
>>   (gdb) print sym
>>   (gdb) xtype
>>   (gdb) xsymbol
>>
>
> (gdb) frame 0
> #0  SYMBOL_NAME (sym=XIL(0x55555f9b3260)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
> 1152	  return p;
> (gdb) print sym
> $1 = XIL(0x55555f9b3260)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0xaaaab57810c0
> Cannot access memory at address 0xaaaab57810c8
> (gdb)

This seems like an entirely bogus object which somehow ended up in the
error list, probably by CHECK_LIST or CHECK_LIST_END.  It's a pointer,
not a tagged Lisp symbol.

Can you examine the memory it points to so we get a clue, maybe?

(gdb) x/64gx 0x55555f9b3200

This may be a GC issue, where the error list is freed and the cons cell
reused (or put on a free list).

Can you reproduce this issue?  It'd be great to generate a core file
("gcore" in gdb) and save it along with the emacs binary and .pdmp file
used in that run.

>> > #5 0x000055555570603b in Fcommand_error_default_function
>> (data=0x55555a8e65c3, context=0x7ffff1880284, signal=0x7fe0) at
>> /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
>>
>> Can you show the error and its data here?  Like this:
>>
>>  (gdb) frame 5
>>  (gdb) pp data
>>  (gdb) pp context
>>
>
> (gdb) frame 5
> #5  0x000055555570603b in Fcommand_error_default_function (data=XIL(0x55555df52d03),
>     context=XIL(0x7ffff1880284), signal=XIL(0x7fe0))
>     at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
> 1679	  return XSTRING (string)->u.s.data;
> (gdb) pp data
> (wrong-type-argument listp

Unfortunately, there are many places that call CHECK_LIST or
CHECK_LIST_END.  If you can set a breakpoint on the function
"wrong_type_argument" (note there may be some false positives), we could
catch the bug before we unwind through the stack and lose the context.

The candidates in treesit.c don't seem obviously incorrect...

Pip