From: Eli Zaretskii <eliz@gnu.org>
To: Yuan Fu <casouri@gmail.com>
Cc: mickey@masteringemacs.org, 60237@debbugs.gnu.org
Subject: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node
Date: Sat, 25 Feb 2023 09:51:32 +0200 [thread overview]
Message-ID: <83sfeukwsb.fsf@gnu.org> (raw)
In-Reply-To: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> (message from Yuan Fu on Fri, 24 Feb 2023 15:22:00 -0800)
> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 24 Feb 2023 15:22:00 -0800
> Cc: eliz@gnu.org,
> 60237@debbugs.gnu.org
>
> I’m stumbled on a reliably way to trigger a crash, of possibly the same cause as
> this one, by enabling the profiler and M-x garbage-collect in a
> tree-sitter mode on Mac. I tried to reproduce this on Linux but with no
> success.
>
> I was also able to trigger infinite loop by the same recipe on time, but I
> didn’t run that session under lldb. Anyway, we can focus on the crash
> first.
>
> Below’s the backtrace. Eli, could you see anything from this?
> [...]
> (lldb) down
> frame #0: 0x0000000100250f3d emacs`ASIZE(array=0x00000001a1889245) at lisp.h:1768:3
> 1765 ASIZE (Lisp_Object array)
> 1766 {
> 1767 ptrdiff_t size = XVECTOR (array)->header.size;
> -> 1768 eassume (0 <= size);
> 1769 return size;
> 1770 }
> 1771
> (lldb) p size
> (ptrdiff_t) $0 = -9223372036854775792
It looks like we are calling ASIZE in the context of GC, when the
vectors have their mark bit set, which makes ASIZE return negative
values: do
(gdb) p/x (unsigned long long)-9223372036854775792
$1 = 0x8000000000000010
So this is 16 (10 hex) with the array mark flag bit set. The fix is
simple:
diff --git a/src/eval.c b/src/eval.c
index 2dd0c35..7e6b742 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -4190,7 +4190,7 @@ mark_specpdl (union specbinding *first, union specbinding *ptr)
get_backtrace (Lisp_Object array)
{
union specbinding *pdl = backtrace_next (backtrace_top ());
- ptrdiff_t i = 0, asize = ASIZE (array);
+ ptrdiff_t i = 0, asize = gc_asize (array);
/* Copy the backtrace contents into working memory. */
for (; i < asize; i++)
> I suspect there is some stupid mistake that I made concerning gcing
> tree-sitter objects. Could you see anything suspicious from the
> following description:
>
> A Lisp_TS_Parser contains a TSParser and a TSTree, which are freed when
> the Lisp_TS_Parser is collected. A Lisp_TS_Node references the parser
> from which it is created, so that a Lisp_TS_Parser is only collected
> when no live node references it, because the Lisp_TS_Node references the
> TSTree stored in the Lisp_TS_Parser.
Sounds good, but do you understand why tree-sitter calls malloc when
you GC a parser? This is what we see in the backtrace:
> * frame #0: 0x0000000100250f3d emacs`ASIZE(array=0x00000001a1889245) at lisp.h:1768:3
> frame #1: 0x0000000100250e5e emacs`get_backtrace(array=0x00000001a1889245) at eval.c:4193:28
> frame #2: 0x00000001003001ce emacs`record_backtrace(log=0x00000001a1887d68, count=64) at profiler.c:162:3
> frame #3: 0x000000010030016d emacs`malloc_probe(size=64) at profiler.c:509:3
> frame #4: 0x0000000100204e6d emacs`xmalloc(size=64) at alloc.c:760:3
> frame #5: 0x0000000100e6c0c9 libtree-sitter.0.dylib`ts_subtree_release + 158
> frame #6: 0x0000000100e6f004 libtree-sitter.0.dylib`ts_tree_delete + 44
> frame #7: 0x0000000100307379 emacs`treesit_delete_parser(lisp_parser=0x00000001a2c0f0e0) at treesit.c:1182:3
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?
next prev parent reply other threads:[~2023-02-25 7:51 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-21 12:24 bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Mickey Petersen
2022-12-24 7:23 ` Eli Zaretskii
2022-12-24 9:20 ` Yuan Fu
2022-12-29 14:21 ` Mickey Petersen
2023-02-24 23:22 ` Yuan Fu
2023-02-25 7:13 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-25 7:51 ` Eli Zaretskii [this message]
2023-02-26 2:01 ` Yuan Fu
2023-02-26 2:37 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-26 6:18 ` Eli Zaretskii
2023-02-26 6:14 ` Eli Zaretskii
2023-02-26 15:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-28 14:00 ` Eli Zaretskii
2023-03-01 4:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-01 13:27 ` Eli Zaretskii
2023-03-01 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-01 15:51 ` Eli Zaretskii
2023-03-01 17:39 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-04 12:21 ` Eli Zaretskii
2023-03-08 16:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-10 18:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-10 20:56 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-11 6:45 ` Eli Zaretskii
2023-03-11 17:45 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-10 23:52 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-11 2:41 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-11 3:29 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-11 3:38 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-02 5:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-02 20:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-26 9:41 ` Mickey Petersen
2023-02-27 0:34 ` Yuan Fu
2023-02-27 8:22 ` Mickey Petersen
2023-02-27 9:05 ` Yuan Fu
2023-02-27 14:29 ` Mickey Petersen
2023-02-27 22:37 ` Yuan Fu
2023-02-27 22:45 ` Dmitry Gutov
2023-02-24 23:29 ` Yuan Fu
2023-02-25 7:55 ` Eli Zaretskii
2023-02-26 2:02 ` Yuan Fu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83sfeukwsb.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=60237@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=mickey@masteringemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.