GNU bug report logs -
#76327
29.4; random segfaults after switch to tree-sitter
Previous Next
Full log
View this message in rfc822 format
"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> 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
This bug report was last modified 116 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.