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

Previous Next

Full log

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

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

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

> 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.
>
> Therefore, deleting a tree is not simply free(). Instead, you
> decrement the refcount of the subtree, and if the count == 0, free the
> data and traverse the subtree and decrementing each children’s
> refcount, and delete them if the count == 0, and so on.

And what will happen if that malloc fails, while *freeing* memory?
Anyway, the profiler should either be fixed to not hook into xmalloc, or
(better) tree-sitter should be fixed to not call xmalloc during GC.

> To traverse the tree, the function uses an array as a stack, which
> calls array_push to push new elements, which may call malloc.

How deep are those trees?

Previous Next

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