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

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Felix <felix.dick <at> web.de>, 70059 <at> debbugs.gnu.org
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 <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Tue, 2 Apr 2024 11:22:44 -0700
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>> 70059 <at> 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

Previous Next

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