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

[Andrea Corallo]

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

> 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?

I should not but it could.

I used my distro's tree-sitter and could not reproduced.

  Andrea