GNU bug report logs - #70059
30.0.50; c-ts-mode crashes emacs

Previous Next

Full log

Message #35 received at 70059 <at> debbugs.gnu.org (full text, mbox):

From: Felix <felix.dick <at> web.de>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70059 <at> debbugs.gnu.org
Subject: Re: bug#70059: 30.0.50; c-ts-mode crashes emacs
Date: Sun, 31 Mar 2024 10:09:33 +0200

Yuan Fu <casouri <at> gmail.com> writes:

>> On Mar 29, 2024, at 5:08 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>> From: Felix <felix.dick <at> web.de>
>>> Cc: Yuan Fu <casouri <at> gmail.com>,  70059 <at> debbugs.gnu.org
>>> Date: Fri, 29 Mar 2024 12:37:03 +0100
>>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>>>> From: Felix <felix.dick <at> web.de>
>>>>> Cc: Andrea Corallo <acorallo <at> gnu.org>,  70059 <at> 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.

Previous Next

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