From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <83sfeukwsb.fsf@gnu.org> References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7836"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mickey@masteringemacs.org, 60237@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 25 08:52:33 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pVpM9-0001vi-IV for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Feb 2023 08:52:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVpLq-0004Lj-1B; Sat, 25 Feb 2023 02:52:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVpLf-0004LW-TN for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 02:52:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVpLe-0001p3-PI for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 02:52:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pVpLe-0003ju-6z for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 02:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Feb 2023 07:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60237 X-GNU-PR-Package: emacs Original-Received: via spool by 60237-submit@debbugs.gnu.org id=B60237.167731150014343 (code B ref 60237); Sat, 25 Feb 2023 07:52:02 +0000 Original-Received: (at 60237) by debbugs.gnu.org; 25 Feb 2023 07:51:40 +0000 Original-Received: from localhost ([127.0.0.1]:38899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVpLI-0003jH-4n for submit@debbugs.gnu.org; Sat, 25 Feb 2023 02:51:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVpLG-0003j3-BJ for 60237@debbugs.gnu.org; Sat, 25 Feb 2023 02:51:38 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVpLA-0001nS-BB; Sat, 25 Feb 2023 02:51:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Y+GVm0x87AMD8/d8dFIloE1ZC2ciBbCfthB0HfmhJa0=; b=gP4PLbW+OyXgrWqrbaju I6DY9lemnn+I/08+z8bDfQ7EEFM/CuZYc2oaHY9RVNwSqZmZLhB+RaFwCB0Z/ZxivBR6l/Z7ltw4O xPFrNIf8ferAgxeLlkB10rINmBki+W7zGsvSXmQ0Z+/Man/b8W9Vu/Ft82JNPfr6+OBWcsn1Gw72G 9e1VRkW3ENeyyscE05csChzJINVo9aS4TEOBiy9+SlsHGBJktStNtAJiH3vVLM6Z1br/fdcHhJpnH qjiVvGfJlGOrTfvPGzZ0w2T9e6WXYPPEF99BkIUUjwfdflwDuKXV9SW32JsYpuQ8PEif89jHzQ8Rw 2c/E8q/g1lFNHg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVpL9-0002Vz-EC; Sat, 25 Feb 2023 02:51:31 -0500 In-Reply-To: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> (message from Yuan Fu on Fri, 24 Feb 2023 15:22:00 -0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256693 Archived-At: > From: Yuan Fu > 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?