GNU bug report logs - #76327
29.4; random segfaults after switch to tree-sitter

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: 76327 <at> debbugs.gnu.org, eliz <at> gnu.org, dushistov <at> mail.ru
Subject: bug#76327: 29.4; random segfaults after switch to tree-sitter
Date: Mon, 17 Feb 2025 20:31:25 +0000

"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes:

> I attached valgrind log,
> may be you can find something usefull.
>
>>> #0  SYMBOL_NAME (sym=XIL(0x55555f9b3260)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
>
>> Can you examine the memory it points to so we get a clue, maybe?
>> (gdb) x/64gx 0x55555f9b3200
>
> So the idea is to use p-0x60, where where p from XIL(p)?

It doesn't have to be 0x60 precisely, just enough to get some context
:-)

In this case, it's enough to let us know that the memory has either been
reused for a new block of cons cells, or that we're looking at a cons
cell which has been freed by GC.

> Here new crash, and x/6gx:
>
> #0  SYMBOL_NAME (sym=0x555577a7a770) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
> 1152	  return p;
> (gdb) print sym
> $1 = (Lisp_Object) 0x555577a7a770
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0xaaaacd8485d0
> Cannot access memory at address 0xaaaacd8485d8
> (gdb) x/64gx 0x555577a7a710
> 0x555577a7a710:	0x0000000000000004	0x0000555577a7a700
> 0x555577a7a720:	0x0000000000000004	0x0000555577a7a710
> 0x555577a7a730:	0x0000000000000004	0x0000555577a7a720
> 0x555577a7a740:	0x0000000000000004	0x0000555577a7a730
> 0x555577a7a750:	0x0000000000000004	0x0000555577a7a740
> 0x555577a7a760:	0x0000000000000004	0x0000555577a7a750
> 0x555577a7a770:	0x0000000000000004	0x0000555577a7a760
> 0x555577a7a780:	0x0000000000000004	0x0000555577a7a770
> 0x555577a7a790:	0x0000000000000004	0x0000555577a7a780
> 0x555577a7a7a0:	0x0000000000000004	0x0000555577a7a790
> 0x555577a7a7b0:	0x0000000000000004	0x0000555577a7a7a0
> 0x555577a7a7c0:	0x0000000000000004	0x0000555577a7a7b0
> 0x555577a7a7d0:	0x0000000000000004	0x0000555577a7a7c0
> 0x555577a7a7e0:	0x0000000000000000	0x0000555577a7a800

That's a cons block, with free cons cells (the car is dead_object(), the
cdr is the link to the next free cons cell).

Then the mark bits (which are all zero, then the link to the next cons
block (immediately afterwards).


> 0x555577a7a7f0:	0x5f74736574225b3a	0x0000555577a77c00

This word reads as the string:

:["test_

but it's probably just leftover from when this wasn't a cons block.

In other words, something may have atttempted to access
XCDR (0x555577a7a763)

As this is quite strange, please try to produce a live GDB session or a
core dump with a "bt full", and then we can walk the cons cells to see
what went wrong.

>>  If you can set a breakpoint on the function
>> "wrong_type_argument" (note there may be some false positives)
>
> "wrong_type_argument" for some reason triggers
> on every attempt to open file.

Yes, it does trigger a lot.  You can restrict the breakpoint to trigger
only when value is Qlistp by doing

b wrong_type_argument if value == Qlistp

then whenever it stops, get a "bt full" and "c" if it doesn't look like
the right one.  The last bt full before the crash will be the
interesting one.

> I will try to rebuild emacs with sanitizer.

--enable-checking=all might help.  The sanitizer might, too, I guess :-)

Pip

Previous Next

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