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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: felix.dick <at> web.de, 70059 <at> debbugs.gnu.org
Subject: bug#70059: 30.0.50; c-ts-mode crashes emacs
Date: Mon, 08 Apr 2024 14:35:58 +0300

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Sun, 7 Apr 2024 23:32:01 -0700
> Cc: Felix <felix.dick <at> web.de>,
>  70059 <at> debbugs.gnu.org
> 
> > On Apr 2, 2024, at 11:34 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> >> 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.

Even if tree-sitter was not compiled with debug symbols, we'd see the
library name in the backtrace.  Like here:

  #14 0x0000723f608fd770 in <signal handler called> () at /usr/lib/libc.so.6
  #15 0x000062534d063429 in process_mark_stack ()
  #16 0x000062534d1649f1 in traverse_intervals_noorder ()
  #17 0x000062534d063e5e in process_mark_stack ()
  #18 0x000062534d063ceb in process_mark_stack ()
  #19 0x000062534d063ceb in process_mark_stack ()
  #20 0x000062534d064fab in mark_char_table ()
  #21 0x000062534d0650f6 in mark_char_table ()

As you see, the fact that the crash happened in libc is shown, even
though we have no symbols for libc.

Looking at the two backtraces posted in this bug, I see that each time
the crashes were while processing some char-table.  I don't think
treesit-related code manipulates char-table's, does it?  So I don't
think treesit-related code is to blame here, it just so happened that
calling treesit-pattern-expand triggered GC; the invalid object was
probably created by some unrelated code.

Previous Next

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