GNU bug report logs - #60237
30.0.50; tree sitter core dumps when I edebug view a node

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Mickey Petersen <mickey <at> masteringemacs.org>
Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>, 60237 <at> debbugs.gnu.org
Subject: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node
Date: Sun, 26 Feb 2023 16:34:49 -0800

> On Feb 26, 2023, at 1:41 AM, Mickey Petersen <mickey <at> masteringemacs.org> wrote:
> 
> 
> Yuan Fu <casouri <at> gmail.com> writes:
> 
>>> GC has historically never called xmalloc, so the profiler will
>>> likely
>>> crash upon growing the mark stack as well.  I guess another
>>> important
>>> question is why ts_delete_parser is calling xmalloc.
>>> 
>> 
>>> As you see, when we call ts_tree_delete, it calls
>>> ts_subtree_release,
>>> which in turn calls malloc (redirected into our xmalloc).  Is this
>>> expected?  Can you look in the tree-sitter sources and verify that
>>> this is OK?
>> 
>> I had a look, and it seems legit. In tree-sitter, a TSTree (or more
>> precisely, a Subtree) is just some inlined data plus a refcounted
>> pointer to the complete data. This way multiple trees share common
>> subtrees/nodes. Eg, when incrementally parsing, you pass in an old
>> tree and get a new tree, these two trees will share the unchanged part
>> of the tree.
> 
> Would that mean we could possibly preserve node instances -- either the real TS ones, or an Emacs-created facsimile -- between incremental parsing? That would be useful for refactoring.

What kind of exact interface (function) do you want? The treesit-node-outdated error is solely Emacs’s product, tree-sitter itself doesn’t mark a node outdated. It is possible for Emacs to not delete the old tree and give it to you, or allow you to access information of an outdated node.

Yuan

Previous Next

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