bug#70059: 30.0.50; c-ts-mode crashes emacs

[Felix]

I think this problem posted on reddit might be related to this issue:
https://www.reddit.com/r/emacs/comments/1c3wpbt/emacs_crashes_with_treesitter_update/


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sun, 7 Apr 2024 23:32:01 -0700
>> Cc: Felix <felix.dick@web.de>,
>>  70059@debbugs.gnu.org
>> 
>> > On Apr 2, 2024, at 11:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > 
>> >> I mean tree-sitter (the library) runs in the main thread, if it triggers 
>> >> a segfault, AFAIK Emacs currently can’t really do anything. Is that right 
>> >> Eli?
>> > 
>> > You are right.  But these crashes seem to be inside GC, which
>> > processes our objects, so if tree-sitter somehow causes us to create
>> > invalid Lisp objects, it's our fault, at least to some extent.
>> 
>> If the crash happens in ts_node_delete, ts_parser_delete or
>> ts_tree_delete, would the backtrace record that? (Given that the
>> tree-sitter library probably isn’g compile with symbols.) If the
>> crash happens in those functions I think it’s not our fault.
>
> Even if tree-sitter was not compiled with debug symbols, we'd see the
> library name in the backtrace.  Like here:
>
>   #14 0x0000723f608fd770 in <signal handler called> () at /usr/lib/libc.so.6
>   #15 0x000062534d063429 in process_mark_stack ()
>   #16 0x000062534d1649f1 in traverse_intervals_noorder ()
>   #17 0x000062534d063e5e in process_mark_stack ()
>   #18 0x000062534d063ceb in process_mark_stack ()
>   #19 0x000062534d063ceb in process_mark_stack ()
>   #20 0x000062534d064fab in mark_char_table ()
>   #21 0x000062534d0650f6 in mark_char_table ()
>
> As you see, the fact that the crash happened in libc is shown, even
> though we have no symbols for libc.
>
> Looking at the two backtraces posted in this bug, I see that each time
> the crashes were while processing some char-table.  I don't think
> treesit-related code manipulates char-table's, does it?  So I don't
> think treesit-related code is to blame here, it just so happened that
> calling treesit-pattern-expand triggered GC; the invalid object was
> probably created by some unrelated code.