[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70059: 30.0.50; c-ts-mode crashes emacs
From: |
Yuan Fu |
Subject: |
bug#70059: 30.0.50; c-ts-mode crashes emacs |
Date: |
Sun, 7 Apr 2024 23:32:01 -0700 |
> On Apr 2, 2024, at 11:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Tue, 2 Apr 2024 11:22:44 -0700
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> 70059@debbugs.gnu.org
>>
>>> 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?
>
> 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.
Yuan