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

[Yuan Fu <casouri@gmail.com>]

> On Mar 31, 2024, at 1:09 AM, Felix <felix.dick@web.de> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>>> On Mar 29, 2024, at 5:08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>>> From: Felix <felix.dick@web.de>
>>>> Cc: Yuan Fu <casouri@gmail.com>,  70059@debbugs.gnu.org
>>>> Date: Fri, 29 Mar 2024 12:37:03 +0100
>>>> 
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>> 
>>>>>> From: Felix <felix.dick@web.de>
>>>>>> Cc: Andrea Corallo <acorallo@gnu.org>,  70059@debbugs.gnu.org
>>>>>> Date: Fri, 29 Mar 2024 11:51:06 +0100
>>>>>> 
>>>>>> I rebuild it without native-compilation, and it still crashes.
>>>>>> Backtrace:
>>>>>> 
>>>>>> #0  0x000077b79c65c32c in ??? () at /usr/lib/libc.so.6
>>>>>> #1  0x000077b79c60b6c8 in raise () at /usr/lib/libc.so.6
>>>>>> #2  0x00005a5a428f94a2 in terminate_due_to_signal ()
>>>>>> #3  0x00005a5a42933c23 in emacs_abort ()
>>>>>> #4  0x00005a5a429ec268 in signal_or_quit ()
>>>>>> #5  0x00005a5a429eb422 in Fsignal ()
>>>>>> #6  0x00005a5a429eb401 in xsignal ()
>>>>>> #7  0x00005a5a429e9aa2 in xsignal2 ()
>>>>>> #8  0x00005a5a429c0865 in wrong_type_argument ()
>>>>>> #9  0x00005a5a42965e1f in Fexpand_file_name ()
>>>>>> #10 0x00005a5a42b3d200 in Fdo_auto_save.7873 ()
>>>>>> #11 0x00005a5a428f9738 in shut_down_emacs ()
>>>>>> #12 0x00005a5a428f946a in terminate_due_to_signal ()
>>>>>> #13 0x00005a5a42935924 in handle_sigsegv ()
>>>>>> #14 0x000077b79c60b770 in <signal handler called> () at /usr/lib/libc.so.6
>>>>>> #15 0x00005a5a429a57f6 in process_mark_stack ()
>>>>>> #16 0x00005a5a429a677b in mark_char_table ()
>>>>>> #17 0x00005a5a429a68c6 in mark_char_table ()
>>>>>> #18 0x00005a5a429a55bd in process_mark_stack ()
>>>>>> #19 0x00005a5a429a677b in mark_char_table ()
>>>>>> #20 0x00005a5a429a68c6 in mark_char_table ()
>>>>>> #21 0x00005a5a429a55bd in process_mark_stack ()
>>>>>> #22 0x00005a5a429a677b in mark_char_table ()
>>>>>> #23 0x00005a5a429a68c6 in mark_char_table ()
>>>>>> #24 0x00005a5a429a55bd in process_mark_stack ()
>>>>>> #25 0x00005a5a429a677b in mark_char_table ()
>>>>>> #26 0x00005a5a429a68c6 in mark_char_table ()
>>>>>> #27 0x00005a5a429a55bd in process_mark_stack ()
>>>>>> #28 0x00005a5a429a569b in process_mark_stack ()
>>>>>> #29 0x00005a5a429a569b in process_mark_stack ()
>>>>>> #30 0x00005a5a429a569b in process_mark_stack ()
>>>>>> #31 0x00005a5a429a7b8e in garbage_collect ()
>>>>>> #32 0x00005a5a429e76e7 in Ffuncall ()
>>>>>> #33 0x00005a5a42a094f7 in mapcar1 ()
>>>>>> #34 0x00005a5a42a091bf in Fmapconcat ()
>>>>>> #35 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>>>>> #36 0x00005a5a429e87b3 in funcall_subr ()
>>>>>> #37 0x00005a5a429e77f6 in Ffuncall ()
>>>>>> #38 0x00005a5a42a094f7 in mapcar1 ()
>>>>>> #39 0x00005a5a42a091bf in Fmapconcat ()
>>>>>> #40 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>>>>> #41 0x00005a5a429e87b3 in funcall_subr ()
>>>>>> #42 0x00005a5a429e77f6 in Ffuncall ()
>>>>>> #43 0x00005a5a42a094f7 in mapcar1 ()
>>>>>> #44 0x00005a5a42a091bf in Fmapconcat ()
>>>>>> #45 0x00005a5a42aca243 in treesit_ensure_query_compiled ()
>>>>>> #46 0x00005a5a42aca5c0 in Ftreesit_query_capture ()
>>>>> 
>>>>> Then it's strange, since it doesn't happen here.  Does it happen for
>>>>> you with any C source file, including those in the Emacs source tree?
>>>>> If this happens only for some files, can you post one such file?
>>>>> 
>>>>> Also, what version of the tree-sitter library are you using, and what
>>>>> version of the C grammar library?
>>>>> 
>>>>> If you can build the emacs-29 branch, can you try reproducing there?
>>>>> 
>>>>> Yuan, any ideas, based on the backtrace?
>>>> 
>>>> I was using tree-sitter build from the git repository, when i use it
>>>> from the official arch linux repos, it doesn't crash (at least until
>>>> now).
>>>> I think this is tree-sitter related, but it shouldn't be able to crash
>>>> emacs, should it?
>>> 
>>> It shouldn't, unless there's some memory-related snafu (which could
>>> explain why the crash is always in GC).  I hope Yuan will be able to
>>> tell.
>> 
>> It’s a bit strange since Ftreesit_pattern_expand doesn’t call
>> tree-sitter function. This function just expands a sexp query like
>> '(function_definition @capture) to a string “(function_definition
>> @capture)”.
>> 
>> Perhaps something it does triggers GC and GC tries to collect some tree-sitter node or parser, and there’s some problem when freeing the node or parser with that version of tree-sitter library.
>> 
>> Also, I couldn’t reproduce with upstream tree-sitter plus emacs master
>> either. I’m using commit 0b4403294981ffb6a51d153a5509a389b91fed86 for
>> tree-sitter and commit 411f46fd365bc0008c58e1fa6bee6a60d841da75 for
>> emacs. Felix, what commit are you using?
>> 
>> Yuan
> 
> It still crashes on my computer if i use:
> GNU Emacs 30.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-03-31
> and
> tree-sitter 0.22.2 (fc15f621334a262039ffaded5937e2844f88da61)
> 
> But as i wrote, it doesn't crash with tree-sitter from the official arch
> linux repos, and because i program in C every day, i switched to the
> stable tree-sitter and had no problems since.
> 
> That's why i asked if a faulty tree-sitter should be able to crash
> emacs. If that is acceptable, this bug report can be closed.

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?

Yuan