From unknown Wed Jun 18 23:13:55 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#60237 <60237@debbugs.gnu.org> To: bug#60237 <60237@debbugs.gnu.org> Subject: Status: 30.0.50; tree sitter core dumps when I edebug view a node Reply-To: bug#60237 <60237@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:13:55 +0000 retitle 60237 30.0.50; tree sitter core dumps when I edebug view a node reassign 60237 emacs submitter 60237 Mickey Petersen severity 60237 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 21 07:29:54 2022 Received: (at submit) by debbugs.gnu.org; 21 Dec 2022 12:29:54 +0000 Received: from localhost ([127.0.0.1]:51564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p7yEL-0006ls-Pl for submit@debbugs.gnu.org; Wed, 21 Dec 2022 07:29:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:43962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p7yEJ-0006lm-80 for submit@debbugs.gnu.org; Wed, 21 Dec 2022 07:29:52 -0500 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 1p7yEJ-0007VJ-3X for bug-gnu-emacs@gnu.org; Wed, 21 Dec 2022 07:29:51 -0500 Received: from mail-cwlgbr01on0723.outbound.protection.outlook.com ([2a01:111:f400:fe14::723] helo=GBR01-CWL-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p7yEG-00068A-8w for bug-gnu-emacs@gnu.org; Wed, 21 Dec 2022 07:29:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UYZMY6CIUZOae4r/xDKTo/PhdbhQynAZOkY50Iwjzxm7Yo+uuQOhJ56Y8krIvohqR8V+Yw8R89awxv1wHiOKnI/GxR6sd4QWozFiLtLxk4GFmSPFQw+58ytAw3STlo5c54drG12vfLkUFL8F4KAuAs5IbGlujJlcDtoqaahU88HfMj86GYkRD+Ulk58hMTfvzfXizj3a1Eh7uOcVHu+/U2UOMplF1hRA6LjsGjdoxwU485x1bA7QjC1QTxWkVwCcWER0dvdCcEQMWPMpqAQAO4e3t2iODFxOshQv7FRxXG7P/4ncqVXBHuMGieXYctfbdG8ye0QBq1bFLf+N/9gDRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GWPQYoOEQM9gZieYJkcnZqYOZ6fr75vikvM2MkhA/Ds=; b=EGCrxlMp+zgQNoCVE+qMLmAb5ocEq+MDcwNwhn20Ds9YDOFhibmXKCOmmIWaL5yvnc1Z2l1qvxydESNAl5wHzvWURKIzXBGH2zbXHg0CbqIqJxgAUi+AZ+b863rzVxwDNgMCOXaGmc2Pf1CCgTe0ZsoWFsqEBXCgRGSmSXqNDK0ZzflwcgBqYr6tRgmndsdhSOXCcC4aeoINb1DJPZ+bVa5e6x9cYzRJ6UKfmG+1VeHeT+i5K+qhMR82PaircIwE4hYzADOGRHWcWTgpxqIDyoGG7ZMQ/yRrQNpi14b2yjDNeNnM/EASMdIRoPFVCAaAzxQWJWftUDv4QAL0mDaNHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 178.79.136.144) smtp.rcpttodomain=gnu.org smtp.mailfrom=masteringemacs.org; dmarc=pass (p=none sp=none pct=100) action=none header.from=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semantical.onmicrosoft.com; s=selector1-semantical-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GWPQYoOEQM9gZieYJkcnZqYOZ6fr75vikvM2MkhA/Ds=; b=dqojnU78vL/MZqgtY59moCoaBa9DqG0HT0kWv/8rskZhrTyKsu9RgXisLp/oXHl/tYMDR4ABD49P4KVO4FQyRA+TyKj8FKOeH6ygeV+Xz9jgfQd9dIqJTmyZoRoAytaTvBLNrTGQ9x3FEGERnPQjoK2/8TbI4iYKrhvotTEsrME= Received: from CWLP123CA0074.GBRP123.PROD.OUTLOOK.COM (2603:10a6:401:5b::14) by CWLP265MB2180.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:64::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5924.16; Wed, 21 Dec 2022 12:24:43 +0000 Received: from CWLGBR01FT030.eop-gbr01.prod.protection.outlook.com (2603:10a6:401:5b:cafe::f) by CWLP123CA0074.outlook.office365.com (2603:10a6:401:5b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5924.21 via Frontend Transport; Wed, 21 Dec 2022 12:24:43 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 178.79.136.144) smtp.mailfrom=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org;dmarc=pass action=none header.from=masteringemacs.org; Received-SPF: Pass (protection.outlook.com: domain of masteringemacs.org designates 178.79.136.144 as permitted sender) receiver=protection.outlook.com; client-ip=178.79.136.144; helo=semantical.co.uk; pr=C Received: from semantical.co.uk (178.79.136.144) by CWLGBR01FT030.mail.protection.outlook.com (10.152.40.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5944.6 via Frontend Transport; Wed, 21 Dec 2022 12:24:43 +0000 Received: by semantical.co.uk (Postfix, from userid 5001) id 0B3E4114002; Wed, 21 Dec 2022 12:24:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=masteringemacs.org; s=masteringemacs.org; t=1671625483; bh=h2iwkkKYQ0iQVX8NwSDuB5BwoDext+lBfRrbGx5oFXs=; h=From:To:Subject:Date:From; b=KePFuBGRAwz5eamJHjA0bwFxfl/W6FCJWyjZHJ9Lu9gg4GcFlGbTUIlH5QyRaoTa9 BoZHj4w0MO3EXfPHnt/Au2qw5fe4K9BKgCIIpfESTi0Rs/RiO8YtHwdR4n5QqCiVSF Xa4CenCpNSfNH8LpWjyCVpktk8ZD3Q3NSvzuagNw= X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on semantical.co.uk X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 From: Mickey Petersen To: bug-gnu-emacs@gnu.org Subject: 30.0.50; tree sitter core dumps when I edebug view a node Date: Wed, 21 Dec 2022 12:24:34 +0000 Message-ID: <87o7rx7xml.fsf@masteringemacs.org> Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CWLGBR01FT030:EE_|CWLP265MB2180:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 99ad4ac2-c919-4854-b428-08dae34e571a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: RXLuuoSS3V8QuvmI08ff8f68xfnHvooKGUvngfndC4XFiR2JuARaGM1pfaoFlF+7kX7P/mZwuNuZV46eipVCodSJIlz9xYMPA+MX7RwK5g0gQ+kXp5KSiainaaDycoFiO/89l7uX0zmM7Ff0mZj0kiCGG7km1clLWZKnW/RZcpfHvYZgDmALu2cAva8Kk8u95WZuG769wBP7T8ePpl5/lnxbIU3hahCGiweHYn3erUy+0XsaWEMZTibJ+eZDzedJzd/Mm57SoLH7wozZTG/ZjBTHsJL3deXsurF8+L/M4ppIsArA7suu9Oyb0B76JIgwIpX/51KcfYJjQIq3CaGvurVDKi3engGbqAKsop9O/sc8htRVoe1tL4OMJHCRJ5cSnL071+LSKKHX4w1inTgMLxA+4pZlo4gvCx2ACie/uj7cc9te2+rtaQaMN6p9FvzOJFXfACnKjmXm1I6YZeCLdtr8EmPRPS9/xRucRhAYokoX66IPk+m0OgSdGSw9NnjR0mTPC6DI32PMKsBHwot1DLp9UKrAZb/670zfQlwYgPZFkNKyrGic5yW72Uf5GdvTqf5A9DGXrLDaFmcNfCZKHiJnqpLGsvbBRvjfagCNlAldII/JcT7kfEnErz96u2CyG0enfDYu0wURhiovygmKOs790GshAvobTesFzgmnG9rSseyw5NmLttwaHnrHle9cDb+Hfgvi+mGSaMdCPsDS8Jg2ew0Y21LKzBkHctTBd/yk+pslGEUD0A2qhWh7NqGj X-Forefront-Antispam-Report: CIP:178.79.136.144; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:semantical.co.uk; PTR:semantical.co.uk; CAT:NONE; SFS:(13230022)(346002)(396003)(376002)(39830400003)(136003)(451199015)(46966006)(36840700001)(316002)(8936002)(47076005)(83380400001)(36756003)(356005)(7636003)(40480700001)(82310400005)(336012)(7596003)(41300700001)(4001150100001)(2906002)(478600001)(6266002)(26005)(6916009)(6666004)(36860700001)(30864003)(186003)(8676002)(86362001)(5660300002)(70586007)(2616005)(42186006)(70206006)(38230200001)(79816003)(14776008); DIR:OUT; SFP:1102; X-OriginatorOrg: masteringemacs.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Dec 2022 12:24:43.4043 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99ad4ac2-c919-4854-b428-08dae34e571a X-MS-Exchange-CrossTenant-Id: a4e27e3d-bab0-45e8-8942-e64cf9fbd34f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a4e27e3d-bab0-45e8-8942-e64cf9fbd34f; Ip=[178.79.136.144]; Helo=[semantical.co.uk] X-MS-Exchange-CrossTenant-AuthSource: CWLGBR01FT030.eop-gbr01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP265MB2180 Received-SPF: pass client-ip=2a01:111:f400:fe14::723; envelope-from=mickey@masteringemacs.org; helo=GBR01-CWL-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Happens in emacs -Q (after loading some simple elisp code that uses treesit.el) and consistently and repeatedly. Here's the elisp. When I edebug it I can step and view all the variables and expressions I like. The `combobulate-' functions are widely used in the library and pose no issues anywhere else and do nothing more than fetch nodes via tree sitter. It is only this bit of code that blows up, and then only when invoked inside a python string. (when-let ((navigable-node (combobulate--get-nearest-navigable-node)) ;; <-- edebugging these work fine; (nearest-node (combobulate-node-at-point)) (targets (seq-filter (lambda (elem) (and elem (< elem (point)))) (list (save-excursion (ignore-errors (backward-up-list 1 t t) (point))) (combobulate-node-point (combobulate--nav-get-parent navigable-node)) ;; <- call into this inner form blows up when I read the argument value of `navigable-node' on the inside. (combobulate-node-point (combobulate--nav-get-parent nearest-node)))))) (when-let (target (apply #'max targets)) (goto-char target) (combobulate--flash-node (combobulate--get-nearest-navigable-node)))) Here is the "fix" (when-let* ((navigable-node (combobulate--get-nearest-navigable-node)) (nearest-node (combobulate-node-at-point)) (navigable-node-parent (combobulate--nav-get-parent navigable-node)) ;; <- refactor out (nearest-node-parent (combobulate--nav-get-parent nearest-node)) ;; <- refactor out (targets (seq-filter (lambda (elem) (and elem (< elem (point)))) (list (save-excursion (ignore-errors (backward-up-list 1 t t) (point))) ; <- smoking gun (combobulate-node-point navigable-node-parent) (combobulate-node-point nearest-node-parent))))) (when-let (target (apply #'max targets)) (goto-char target) (combobulate--flash-node (combobulate--get-nearest-navigable-node)))) Clearly, `ignore-errors' + `backward-up-list' which throws errors left and right if it doesn't like what it's seeing is causing this. If I instead of edebugging just run the code, it hangs Emacs. I have to kill -9 it. Core dump's half a gig; not going to attach it. --- Backtrace from the dump here --- #0 raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x000055e6f87a8e21 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=-117776184, backtrace_limit@entry=40) at emacs.c:464 #2 0x000055e6f87a933d in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1783 #3 0x000055e6f8901f2d in deliver_thread_signal (sig=sig@entry=11, handler=0x55e6f87a932c ) at sysdep.c:1775 #4 0x000055e6f8901fad in deliver_fatal_thread_signal (sig=11) at sysdep.c:1888 #5 handle_sigsegv (sig=11, siginfo=, arg=) at sysdep.c:1888 #6 0x00007fb676b683c0 in () at /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x00007fb674ea6574 in ts_language_symbol_count () at /usr/local/lib/libtree-sitter.so.0 #8 0x00007fb674ea6773 in ts_language_symbol_name () at /usr/local/lib/libtree-sitter.so.0 #9 0x000055e6f8a01ca5 in Ftreesit_node_type (node=node@entry=XIL(0x55e6fdb98f2d)) at treesit.c:1705 #10 0x000055e6f899ee4d in print_vectorlike (obj=XIL(0x55e6fdb98f2d), printcharfun=XIL(0), escapeflag=, buf=0x7ffe8098a210 "\335M\351\371\346U") at print.c:2040 #11 0x000055e6f899cb51 in print_object (obj=XIL(0x55e6fdb98f2d), printcharfun=XIL(0), escapeflag=true) at print.c:2612 #12 0x000055e6f899d42c in Fprin1 (object=XIL(0x55e6fdb98f2d), printcharfun=XIL(0x55e6fd9fcdd5), overrides=) at print.c:777 #13 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) at lisp.h:2204 #14 0x000055e6f89735f7 in Ffuncall (nargs=3, args=0x7ffe8098a530) at eval.c:2995 #15 0x000055e6f8973880 in Fapply (nargs=2, args=0x7fb66f8327a8) at eval.c:2666 #16 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) at lisp.h:2204 #17 0x000055e6f89735f7 in Ffuncall (nargs=4, args=0x7ffe8098a680) at eval.c:2995 #18 0x000055e6f8973880 in Fapply (nargs=3, args=0x7fb66f832700) at eval.c:2666 #19 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) at lisp.h:2204 #20 0x000055e6f89735f7 in Ffuncall (nargs=3, args=0x7fb66f832660) at eval.c:2995 #21 0x000055e6f8973b0a in Fapply (nargs=3, args=0x7fb66f832660) at eval.c:2623 #22 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) at lisp.h:2204 #23 0x000055e6f89bc366 in exec_byte_code (fun=, args_template=, nargs=, args=) at bytecode.c:811 #24 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7ffe8098a9f8) at eval.c:2995 #25 0x000055e6f896f293 in Ffuncall_interactively (nargs=3, args=0x7ffe8098a9f8) at callint.c:248 #26 0x000055e6f89735f7 in Ffuncall (nargs=4, args=0x7ffe8098a9f0) at eval.c:2995 #27 0x000055e6f8973880 in Fapply (nargs=nargs@entry=3, args=args@entry=0x7ffe8098ab60) at eval.c:2666 #28 0x000055e6f8970c57 in Fcall_interactively (function=XIL(0x3a90730), record_flag=XIL(0), keys=XIL(0x55e6fd9f8a6d)) at lisp.h:1171 #29 0x00007fb6706bdc95 in F636f6d6d616e642d65786563757465_command_execute_0 () at /home/mickey/Downloads/emacs/src/../native-lisp/30.0.50-7cb43add/preloaded/simple-fab5b0cf-b9ebea66.eln #30 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7ffe8098ad10) at eval.c:2995 #31 0x000055e6f88f5ea0 in call1 (arg1=, fn=XIL(0x4c20)) at lisp.h:3247 #32 command_loop_1 () at keyboard.c:1495 #33 0x000055e6f8971bf7 in internal_condition_case (bfun=bfun@entry=0x55e6f88f5a80 , handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55e6f88e8b60 ) at eval.c:1474 #34 0x000055e6f88e11ea in command_loop_2 (handlers=handlers@entry=XIL(0x90)) at keyboard.c:1125 #35 0x000055e6f8971b39 in internal_catch (tag=tag@entry=XIL(0x6b10), func=func@entry=0x55e6f88e11c0 , arg=arg@entry=XIL(0x90)) at eval.c:1197 #36 0x000055e6f88e113c in command_loop () at lisp.h:1171 #37 0x000055e6f88e86b8 in recursive_edit_1 () at keyboard.c:712 #38 0x000055e6f88e8a60 in Frecursive_edit () at keyboard.c:795 #39 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) at lisp.h:2204 #40 0x000055e6f89735f7 in Ffuncall (nargs=3, args=0x7fb66f8323d8) at eval.c:2995 #41 0x000055e6f8973b0a in Fapply (nargs=3, args=0x7fb66f8323d8) at eval.c:2623 #42 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) at lisp.h:2204 #43 0x000055e6f8978c0f in apply_lambda (fun=, args=, count=...) at eval.c:3103 #44 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 #45 0x000055e6f8978bce in apply_lambda (fun=, args=, count=...) at eval.c:3098 #46 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 #47 0x000055e6f897862d in Fprogn (body=XIL(0)) at eval.c:436 #48 funcall_lambda (fun=XIL(0x55e6fc3bf1f3), nargs=0, arg_vector=0x7fb66f832168) at eval.c:3233 #49 0x000055e6f89bc366 in exec_byte_code (fun=, args_template=, nargs=, args=) at bytecode.c:811 #50 0x000055e6f8978c0f in apply_lambda (fun=, args=, count=...) at eval.c:3103 #51 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 #52 0x000055e6f897862d in Fprogn (body=XIL(0)) at eval.c:436 #53 funcall_lambda (fun=XIL(0x55e6f9db7153), nargs=1, arg_vector=0x7ffe8098b670) at eval.c:3233 #54 0x000055e6f8978c0f in apply_lambda (fun=, args=, count=...) at eval.c:3103 #55 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 #56 0x000055e6f8978bce in apply_lambda (fun=, args=, count=...) at eval.c:3098 #57 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 #58 0x000055e6f897723d in eval_sub (form=) at eval.c:2465 #59 0x000055e6f8978bce in apply_lambda (fun=, args=, count=...) at eval.c:3098 #60 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 #61 0x000055e6f897774d in Fand (args=XIL(0)) at eval.c:370 #62 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 #63 0x000055e6f8979496 in FletX (args=XIL(0x55e6fd7f83c3)) at lisp.h:1522 #64 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 #65 0x000055e6f8977f97 in Fprog1 (args=XIL(0x55e6fd7f7c13)) at lisp.h:1516 #66 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 #67 0x000055e6f89797eb in Funwind_protect (args=XIL(0x55e6fd7f7c73)) at lisp.h:1516 #68 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 #69 0x000055e6f8979235 in Fprogn (body=XIL(0)) at eval.c:436 #70 Flet (args=) at eval.c:1026 #71 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 #72 0x000055e6f8979235 in Fprogn (body=XIL(0)) at eval.c:436 #73 Flet (args=) at eval.c:1026 #74 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 #75 0x000055e6f8977ef5 in Fprogn (body=XIL(0x55e6fd8a41b3)) at eval.c:436 #76 prog_ignore (body=XIL(0x55e6fd7f7e03)) at eval.c:447 #77 Fwhile (args=) at eval.c:1047 #78 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 #79 0x000055e6f897964d in Fprogn (body=XIL(0)) at eval.c:436 #80 FletX (args=XIL(0x55e6fd7f7eb3)) at eval.c:958 #81 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 #82 0x000055e6f897862d in Fprogn (body=XIL(0)) at eval.c:436 #83 funcall_lambda (fun=XIL(0x55e6fd7f7f93), nargs=1, arg_vector=0x7ffe8098c4e0) at eval.c:3233 #84 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7ffe8098c4d8) at eval.c:2995 #85 0x000055e6f896f293 in Ffuncall_interactively (nargs=2, args=0x7ffe8098c4d8) at callint.c:248 #86 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7ffe8098c4d0) at eval.c:2995 #87 0x000055e6f89708d3 in Fcall_interactively (function=, record_flag=, keys=) at callint.c:785 #88 0x00007fb6706bdc95 in F636f6d6d616e642d65786563757465_command_execute_0 () at /home/mickey/Downloads/emacs/src/../native-lisp/30.0.50-7cb43add/preloaded/simple-fab5b0cf-b9ebea66.eln #89 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7ffe8098c7b0) at eval.c:2995 #90 0x000055e6f88f5ea0 in call1 (arg1=, fn=XIL(0x4c20)) at lisp.h:3247 #91 command_loop_1 () at keyboard.c:1495 #92 0x000055e6f8971bf7 in internal_condition_case (bfun=bfun@entry=0x55e6f88f5a80 , handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55e6f88e8b60 ) at eval.c:1474 #93 0x000055e6f88e11ea in command_loop_2 (handlers=handlers@entry=XIL(0x90)) at keyboard.c:1125 #94 0x000055e6f8971b39 in internal_catch (tag=tag@entry=XIL(0xffc0), func=func@entry=0x55e6f88e11c0 , arg=arg@entry=XIL(0x90)) at eval.c:1197 #95 0x000055e6f88e1186 in command_loop () at lisp.h:1171 #96 0x000055e6f88e86b8 in recursive_edit_1 () at keyboard.c:712 #97 0x000055e6f88e8a60 in Frecursive_edit () at keyboard.c:795 #98 0x000055e6f87b23b8 in main (argc=, argv=) at emacs.c:2529 --- END --- In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-11-29 built on mickey-work Repository revision: 7939184f8e0370e7a3397d492812c6d202c2a193 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12013000 System Description: Ubuntu 20.04.3 LTS Configured using: 'configure --with-native-compilation --with-json --with-mailutils --without-compress-install --with-imagemagick CC=gcc-10' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_MONETARY: en_GB.UTF-8 value of $LC_NUMERIC: en_GB.UTF-8 value of $LC_TIME: en_GB.UTF-8 value of $LANG: en_GB.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 24 02:23:46 2022 Received: (at 60237) by debbugs.gnu.org; 24 Dec 2022 07:23:46 +0000 Received: from localhost ([127.0.0.1]:41377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p8ysj-0002YB-MV for submit@debbugs.gnu.org; Sat, 24 Dec 2022 02:23:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38140) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p8ysg-0002Y5-DJ for 60237@debbugs.gnu.org; Sat, 24 Dec 2022 02:23:45 -0500 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 1p8ysa-0001er-BX; Sat, 24 Dec 2022 02:23:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Kuq7xgfB9LZp4AqGyLP+kEiwFb0H4JB2uyigaqozIrE=; b=CZg9BPaVQJQN Ih1JUFXA5FK/RhlhqgmLG6tYgYgkhgqjzj7EHBEfahER8z5fP+Wh+P4TpGJuShx/JC49tFvQSr3s/ JEJFW6L9iMD240HG/8fiuR9gGik4gkxBwfmKChmOiKy+DgsK1PHyAZ9Qdx3UcAAIual+N9Q8Kb8nz jMDz3kRU0EeiHwU5X/a1LgjLB1veTKEXavFftIv0xjPfT3PTbe6AUpVmF7/EEcnRA/xz/vM1G64gw 7yW2c1FhOTWhsR2Y//d0kpcBltwa8MJkSsbpiYYdPDw48BENbpR6FOu60WPa01/haM7v3idIV8coy 2z2n/6YhsLBkSISS12QXXw==; 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 1p8ysZ-0005Xn-EM; Sat, 24 Dec 2022 02:23:36 -0500 Date: Sat, 24 Dec 2022 09:23:32 +0200 Message-Id: <83tu1l5kp7.fsf@gnu.org> From: Eli Zaretskii To: Mickey Petersen , Yuan Fu In-Reply-To: <87o7rx7xml.fsf@masteringemacs.org> (message from Mickey Petersen on Wed, 21 Dec 2022 12:24:34 +0000) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <87o7rx7xml.fsf@masteringemacs.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mickey Petersen > Date: Wed, 21 Dec 2022 12:24:34 +0000 Yuan, can you look into this? The crash is in tree-sitter, so maybe it isn't our bug, but I'd like to be sure. And even if it is a tree-sitter bug, maybe we can work around it to prevent Emacs from crashing? > Happens in emacs -Q (after loading some simple elisp code that uses treesit.el) and consistently and repeatedly. > > > Here's the elisp. When I edebug it I can step and view all the variables and expressions I like. The `combobulate-' functions are widely used in the library and pose no issues anywhere else and do nothing more than fetch nodes via tree sitter. It is only this bit of code that blows up, and then only when invoked inside a python string. > > > > (when-let ((navigable-node (combobulate--get-nearest-navigable-node)) ;; <-- edebugging these work fine; > (nearest-node (combobulate-node-at-point)) > (targets (seq-filter > (lambda (elem) (and elem (< elem (point)))) > (list (save-excursion (ignore-errors (backward-up-list 1 t t) (point))) > (combobulate-node-point (combobulate--nav-get-parent navigable-node)) ;; <- call into this inner form blows up when I read the argument value of `navigable-node' on the inside. > (combobulate-node-point (combobulate--nav-get-parent nearest-node)))))) > (when-let (target (apply #'max targets)) > (goto-char target) > (combobulate--flash-node (combobulate--get-nearest-navigable-node)))) > > Here is the "fix" > > (when-let* ((navigable-node (combobulate--get-nearest-navigable-node)) > (nearest-node (combobulate-node-at-point)) > (navigable-node-parent (combobulate--nav-get-parent navigable-node)) ;; <- refactor out > (nearest-node-parent (combobulate--nav-get-parent nearest-node)) ;; <- refactor out > (targets (seq-filter > (lambda (elem) (and elem (< elem (point)))) > (list (save-excursion (ignore-errors (backward-up-list 1 t t) (point))) ; <- smoking gun > (combobulate-node-point navigable-node-parent) > (combobulate-node-point nearest-node-parent))))) > (when-let (target (apply #'max targets)) > (goto-char target) > (combobulate--flash-node (combobulate--get-nearest-navigable-node)))) > > Clearly, `ignore-errors' + `backward-up-list' which throws errors left and right if it doesn't like what it's seeing is causing this. > > If I instead of edebugging just run the code, it hangs Emacs. I have to kill -9 it. > > > Core dump's half a gig; not going to attach it. > > > --- Backtrace from the dump here --- > > #0 raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x000055e6f87a8e21 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=-117776184, backtrace_limit@entry=40) at emacs.c:464 > #2 0x000055e6f87a933d in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1783 > #3 0x000055e6f8901f2d in deliver_thread_signal (sig=sig@entry=11, handler=0x55e6f87a932c ) at sysdep.c:1775 > #4 0x000055e6f8901fad in deliver_fatal_thread_signal (sig=11) at sysdep.c:1888 > #5 handle_sigsegv (sig=11, siginfo=, arg=) at sysdep.c:1888 > #6 0x00007fb676b683c0 in () at /lib/x86_64-linux-gnu/libpthread.so.0 > #7 0x00007fb674ea6574 in ts_language_symbol_count () at /usr/local/lib/libtree-sitter.so.0 > #8 0x00007fb674ea6773 in ts_language_symbol_name () at /usr/local/lib/libtree-sitter.so.0 > #9 0x000055e6f8a01ca5 in Ftreesit_node_type (node=node@entry=XIL(0x55e6fdb98f2d)) at treesit.c:1705 > #10 0x000055e6f899ee4d in print_vectorlike > (obj=XIL(0x55e6fdb98f2d), printcharfun=XIL(0), escapeflag=, buf=0x7ffe8098a210 "\335M\351\371\346U") at print.c:2040 > #11 0x000055e6f899cb51 in print_object (obj=XIL(0x55e6fdb98f2d), printcharfun=XIL(0), escapeflag=true) at print.c:2612 > #12 0x000055e6f899d42c in Fprin1 (object=XIL(0x55e6fdb98f2d), printcharfun=XIL(0x55e6fd9fcdd5), overrides=) at print.c:777 > #13 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) > at lisp.h:2204 > #14 0x000055e6f89735f7 in Ffuncall (nargs=3, args=0x7ffe8098a530) at eval.c:2995 > #15 0x000055e6f8973880 in Fapply (nargs=2, args=0x7fb66f8327a8) at eval.c:2666 > #16 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) > at lisp.h:2204 > #17 0x000055e6f89735f7 in Ffuncall (nargs=4, args=0x7ffe8098a680) at eval.c:2995 > #18 0x000055e6f8973880 in Fapply (nargs=3, args=0x7fb66f832700) at eval.c:2666 > #19 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) > at lisp.h:2204 > #20 0x000055e6f89735f7 in Ffuncall (nargs=3, args=0x7fb66f832660) at eval.c:2995 > #21 0x000055e6f8973b0a in Fapply (nargs=3, args=0x7fb66f832660) at eval.c:2623 > #22 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) > at lisp.h:2204 > #23 0x000055e6f89bc366 in exec_byte_code (fun=, args_template=, nargs=, args=) > at bytecode.c:811 > #24 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7ffe8098a9f8) at eval.c:2995 > #25 0x000055e6f896f293 in Ffuncall_interactively (nargs=3, args=0x7ffe8098a9f8) at callint.c:248 > #26 0x000055e6f89735f7 in Ffuncall (nargs=4, args=0x7ffe8098a9f0) at eval.c:2995 > #27 0x000055e6f8973880 in Fapply (nargs=nargs@entry=3, args=args@entry=0x7ffe8098ab60) at eval.c:2666 > #28 0x000055e6f8970c57 in Fcall_interactively (function=XIL(0x3a90730), record_flag=XIL(0), keys=XIL(0x55e6fd9f8a6d)) at lisp.h:1171 > #29 0x00007fb6706bdc95 in F636f6d6d616e642d65786563757465_command_execute_0 () > at /home/mickey/Downloads/emacs/src/../native-lisp/30.0.50-7cb43add/preloaded/simple-fab5b0cf-b9ebea66.eln > #30 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7ffe8098ad10) at eval.c:2995 > #31 0x000055e6f88f5ea0 in call1 (arg1=, fn=XIL(0x4c20)) at lisp.h:3247 > #32 command_loop_1 () at keyboard.c:1495 > #33 0x000055e6f8971bf7 in internal_condition_case > (bfun=bfun@entry=0x55e6f88f5a80 , handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55e6f88e8b60 ) > at eval.c:1474 > #34 0x000055e6f88e11ea in command_loop_2 (handlers=handlers@entry=XIL(0x90)) at keyboard.c:1125 > #35 0x000055e6f8971b39 in internal_catch > (tag=tag@entry=XIL(0x6b10), func=func@entry=0x55e6f88e11c0 , arg=arg@entry=XIL(0x90)) at eval.c:1197 > #36 0x000055e6f88e113c in command_loop () at lisp.h:1171 > #37 0x000055e6f88e86b8 in recursive_edit_1 () at keyboard.c:712 > #38 0x000055e6f88e8a60 in Frecursive_edit () at keyboard.c:795 > #39 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) > at lisp.h:2204 > #40 0x000055e6f89735f7 in Ffuncall (nargs=3, args=0x7fb66f8323d8) at eval.c:2995 > #41 0x000055e6f8973b0a in Fapply (nargs=3, args=0x7fb66f8323d8) at eval.c:2623 > #42 0x000055e6f89bc627 in exec_byte_code (fun=, args_template=, nargs=, args=) > at lisp.h:2204 > #43 0x000055e6f8978c0f in apply_lambda (fun=, args=, count=...) at eval.c:3103 > #44 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 > #45 0x000055e6f8978bce in apply_lambda (fun=, args=, count=...) at eval.c:3098 > #46 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 > #47 0x000055e6f897862d in Fprogn (body=XIL(0)) at eval.c:436 > #48 funcall_lambda (fun=XIL(0x55e6fc3bf1f3), nargs=0, arg_vector=0x7fb66f832168) at eval.c:3233 > #49 0x000055e6f89bc366 in exec_byte_code (fun=, args_template=, nargs=, args=) > at bytecode.c:811 > #50 0x000055e6f8978c0f in apply_lambda (fun=, args=, count=...) at eval.c:3103 > #51 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 > #52 0x000055e6f897862d in Fprogn (body=XIL(0)) at eval.c:436 > #53 funcall_lambda (fun=XIL(0x55e6f9db7153), nargs=1, arg_vector=0x7ffe8098b670) at eval.c:3233 > #54 0x000055e6f8978c0f in apply_lambda (fun=, args=, count=...) at eval.c:3103 > #55 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 > #56 0x000055e6f8978bce in apply_lambda (fun=, args=, count=...) at eval.c:3098 > #57 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 > #58 0x000055e6f897723d in eval_sub (form=) at eval.c:2465 > #59 0x000055e6f8978bce in apply_lambda (fun=, args=, count=...) at eval.c:3098 > #60 0x000055e6f8976d4b in eval_sub (form=) at eval.c:2588 > #61 0x000055e6f897774d in Fand (args=XIL(0)) at eval.c:370 > #62 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 > #63 0x000055e6f8979496 in FletX (args=XIL(0x55e6fd7f83c3)) at lisp.h:1522 > #64 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 > #65 0x000055e6f8977f97 in Fprog1 (args=XIL(0x55e6fd7f7c13)) at lisp.h:1516 > #66 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 > #67 0x000055e6f89797eb in Funwind_protect (args=XIL(0x55e6fd7f7c73)) at lisp.h:1516 > #68 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 > #69 0x000055e6f8979235 in Fprogn (body=XIL(0)) at eval.c:436 > #70 Flet (args=) at eval.c:1026 > #71 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 > #72 0x000055e6f8979235 in Fprogn (body=XIL(0)) at eval.c:436 > #73 Flet (args=) at eval.c:1026 > #74 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 > #75 0x000055e6f8977ef5 in Fprogn (body=XIL(0x55e6fd8a41b3)) at eval.c:436 > #76 prog_ignore (body=XIL(0x55e6fd7f7e03)) at eval.c:447 > #77 Fwhile (args=) at eval.c:1047 > #78 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 > #79 0x000055e6f897964d in Fprogn (body=XIL(0)) at eval.c:436 > #80 FletX (args=XIL(0x55e6fd7f7eb3)) at eval.c:958 > #81 0x000055e6f8977428 in eval_sub (form=) at lisp.h:2204 > #82 0x000055e6f897862d in Fprogn (body=XIL(0)) at eval.c:436 > #83 funcall_lambda (fun=XIL(0x55e6fd7f7f93), nargs=1, arg_vector=0x7ffe8098c4e0) at eval.c:3233 > #84 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7ffe8098c4d8) at eval.c:2995 > #85 0x000055e6f896f293 in Ffuncall_interactively (nargs=2, args=0x7ffe8098c4d8) at callint.c:248 > #86 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7ffe8098c4d0) at eval.c:2995 > #87 0x000055e6f89708d3 in Fcall_interactively (function=, record_flag=, keys=) > at callint.c:785 > #88 0x00007fb6706bdc95 in F636f6d6d616e642d65786563757465_command_execute_0 () > at /home/mickey/Downloads/emacs/src/../native-lisp/30.0.50-7cb43add/preloaded/simple-fab5b0cf-b9ebea66.eln > #89 0x000055e6f89735f7 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7ffe8098c7b0) at eval.c:2995 > #90 0x000055e6f88f5ea0 in call1 (arg1=, fn=XIL(0x4c20)) at lisp.h:3247 > #91 command_loop_1 () at keyboard.c:1495 > #92 0x000055e6f8971bf7 in internal_condition_case > (bfun=bfun@entry=0x55e6f88f5a80 , handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55e6f88e8b60 ) > at eval.c:1474 > #93 0x000055e6f88e11ea in command_loop_2 (handlers=handlers@entry=XIL(0x90)) at keyboard.c:1125 > #94 0x000055e6f8971b39 in internal_catch > (tag=tag@entry=XIL(0xffc0), func=func@entry=0x55e6f88e11c0 , arg=arg@entry=XIL(0x90)) at eval.c:1197 > #95 0x000055e6f88e1186 in command_loop () at lisp.h:1171 > #96 0x000055e6f88e86b8 in recursive_edit_1 () at keyboard.c:712 > #97 0x000055e6f88e8a60 in Frecursive_edit () at keyboard.c:795 > #98 0x000055e6f87b23b8 in main (argc=, argv=) at emacs.c:2529 > > --- END --- > > > > In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version > 3.24.20, cairo version 1.16.0) of 2022-11-29 built on mickey-work > Repository revision: 7939184f8e0370e7a3397d492812c6d202c2a193 > Repository branch: master > Windowing system distributor 'The X.Org Foundation', version 11.0.12013000 > System Description: Ubuntu 20.04.3 LTS > > Configured using: > 'configure --with-native-compilation --with-json --with-mailutils > --without-compress-install --with-imagemagick CC=gcc-10' > > Configured features: > ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ > IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 > M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP > SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE > XIM XINPUT2 XPM GTK3 ZLIB > > Important settings: > value of $LC_MONETARY: en_GB.UTF-8 > value of $LC_NUMERIC: en_GB.UTF-8 > value of $LC_TIME: en_GB.UTF-8 > value of $LANG: en_GB.UTF-8 > value of $XMODIFIERS: @im=ibus > locale-coding-system: utf-8-unix > > > > > > From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 24 04:20:29 2022 Received: (at 60237) by debbugs.gnu.org; 24 Dec 2022 09:20:29 +0000 Received: from localhost ([127.0.0.1]:41929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p90hh-0003s1-0N for submit@debbugs.gnu.org; Sat, 24 Dec 2022 04:20:29 -0500 Received: from mail-pj1-f49.google.com ([209.85.216.49]:46846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p90hf-0003rt-0R for 60237@debbugs.gnu.org; Sat, 24 Dec 2022 04:20:27 -0500 Received: by mail-pj1-f49.google.com with SMTP id u4-20020a17090a518400b00223f7eba2c4so6890787pjh.5 for <60237@debbugs.gnu.org>; Sat, 24 Dec 2022 01:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=svlSW+nuRCGHKyAWmcgDpuaF7m/lb0kYCZILvpAeJ2I=; b=Ctg06DJcly7Rjm4o1fCQzHEIrm4zafitDqL1crmAtFFUlzarHlV9Bv8SIcJ6WIFw7D GcqhLnLtFejKubwT//fzE86Am6Bx5LfFJvrfjzprZva5T7L+xvlWO7birz6rAQjSydPn 97X1iRRZxUy1TqM3QOPpA2cfAU5ZPV7MycJq2XzFNw4pN4/u41pAG+OQSX/vU6/hlsgI IMUhfy3RMMvvCFpNYQvJcOqoe13cnZOOL2EEC2oNGY422iegx/Xbf9Z4kW7GJEsLWCPd 82FW+uJTfGmkQvvZvHVJvHs+NRa7w6ZoAeGrj2ZPIWXYIfNF6LNTGYUSMJbg7DvtN9Pd jaVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=svlSW+nuRCGHKyAWmcgDpuaF7m/lb0kYCZILvpAeJ2I=; b=G0PQNXlo1vfacP1kqjSTfTROCSD1HAmyinyp2/ywJKYyRxlt4U6BrcW+xFf/ajN5hW Eu3qd4HXenTVyu6r2Naq0nQgP8lauMMra02lMAYyw0ER4NMJc/+VfBxLFRUCgyS1TY+9 gpy0It+bwT9QR5uY9O6XJNPnfWDctX+5ZCNevB2w/nsXYk5Nct/Cv9KQinb4nyYhHIlj OAqv99400EAr9fIaMNI3YAVxUyR0fM4EA+cnhBn1KfLPmEcXfCC6iw6q7iOucjFg2lLc uj6SMp3VaYoCfrGZ18OsJdWlML33u/g9wJQxNxiwCdVtO4D/DGqYciMGbtkBbZpiQObD 9E2Q== X-Gm-Message-State: AFqh2kqCY1tyzTcTeHoiYLyxkrdlMO4kEx1qe2ti9FJ3rOVhA+zTNGJ0 cNpoA1HO/hv6WemnF+H/SIM= X-Google-Smtp-Source: AMrXdXteSIHzAPwuxRlW1PlJAOg1KOlQosvlllqjD0EOcDqyfAv081Ohf6vQbsFEqtOHP/ig1oyOgQ== X-Received: by 2002:a17:903:258d:b0:18f:a70d:d686 with SMTP id jb13-20020a170903258d00b0018fa70dd686mr12280938plb.2.1671873621035; Sat, 24 Dec 2022 01:20:21 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id i2-20020a170902c94200b00189618fc2d8sm3630596pla.242.2022.12.24.01.20.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Dec 2022 01:20:20 -0800 (PST) From: Yuan Fu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Message-Id: <8A17A5F6-D286-4C3B-9ACB-1751ADE21AB8@gmail.com> Date: Sat, 24 Dec 2022 01:20:19 -0800 To: Eli Zaretskii X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Mickey Petersen , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Mickey Petersen >> Date: Wed, 21 Dec 2022 12:24:34 +0000 > > Yuan, can you look into this? The crash is in tree-sitter, so maybe > it isn't our bug, but I'd like to be sure. And even if it is a > tree-sitter bug, maybe we can work around it to prevent Emacs from > crashing? Absolutely. >> Happens in emacs -Q (after loading some simple elisp code that uses = treesit.el) and consistently and repeatedly. >>=20 >>=20 >> Here's the elisp. When I edebug it I can step and view all the >> variables and expressions I like. The `combobulate-' functions are >> widely used in the library and pose no issues anywhere else and do >> nothing more than fetch nodes via tree sitter. It is only this bit of >> code that blows up, and then only when invoked inside a python >> string. It would be nice if you can make a reproduce recipe. Judging from the backtrace, you can probably trigger it by printing the node with print or princ. And does it trigger on all python strings? Or some specific string in some specific python source? Yuan From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 09:23:44 2022 Received: (at 60237) by debbugs.gnu.org; 29 Dec 2022 14:23:44 +0000 Received: from localhost ([127.0.0.1]:59602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pAtou-0006zl-4d for submit@debbugs.gnu.org; Thu, 29 Dec 2022 09:23:44 -0500 Received: from mail-cwlgbr01on2102.outbound.protection.outlook.com ([40.107.11.102]:6065 helo=GBR01-CWL-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pAtor-0006zV-BF for 60237@debbugs.gnu.org; Thu, 29 Dec 2022 09:23:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H0vY/A8pB+gzzo0Tdamh+p10wq6t62Z5sOqpddD6w72wpMSBNCdjLs12sxCPWKcn3suvjx8a3YYlFV5Qv4aYllz0DMJ2uyDUN9KSrpzM+CChlYFi3Bi5gj3n04TfqkQW1TO1Q+Rro/HaTdghnNEyUGDQAm2KMMYeIVadY8NH0ztvtN8FkTsy6vtRjSUUHxaFgieNr9Ax0Fw6tSsGMi5lxVtRcHuqheSX/ezr9gtl7zqCqNoaMor/AF9BcJWoCaflP5IyZiMJVKs/j/E+YNjuFJmCPoYRr8MrfCvK8xOrtH8rem+ldhGbJJ/T5wUkC91dHTrj3ELZDIBSSlprrUHMfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tuhdcVcMd0capR+6znm2IjAYC2QKiQEBT/Ck/BX9SHM=; b=ebcIWDQxNctVJGGl7UUG4rlWQASUC/UE5q5Ahrg/3b8EBOHsAd2opUdRmZVb1Iy+RSjczTQ6LxFkodc3n7hJnuYdGPdMTQCb67pwoL1bbze1sbSeZk4wvJsff4Qw3J53otrUdn4+8LFU3VD+OtDaG4kt/H3Pzug9eQqGEc/ZElk+sqL33fdZoIZf4c7/mwYLzTT3Fm1OvFuTY+yWwxbEKVHcWTd4v3W7xGa+uZnOC4C+BZYg8Vlii/dTXE/46qVc6L/z8o6B/JSO+HQW98/auGbTzRAnkC9c1C3WA/+rXFZv9hvsyP8AsXPRiC4flHgaRLr1CB1V1R++u+EQtKdG3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 178.79.136.144) smtp.rcpttodomain=debbugs.gnu.org smtp.mailfrom=masteringemacs.org; dmarc=pass (p=none sp=none pct=100) action=none header.from=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semantical.onmicrosoft.com; s=selector1-semantical-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tuhdcVcMd0capR+6znm2IjAYC2QKiQEBT/Ck/BX9SHM=; b=0hz6EKdaa5p85aS1s9LHNG1tokB6c+4/1dvVcTJZ3YiHeucYhBwxBpT7l5ZTBAxTll/8AZfDTzQhuQIeDevIYWo5gi15iomr1XljJ/1YllHjgvgN058FHU5l3dtooVmN9AM9OPk+52CeeNyr8C8q2geh72nQiLZ9ddnONWu7F4g= Received: from LO3P123CA0009.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::14) by LO0P265MB6320.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:244::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5944.16; Thu, 29 Dec 2022 14:23:34 +0000 Received: from LO2GBR01FT022.eop-gbr01.prod.protection.outlook.com (2603:10a6:600:ba:cafe::2d) by LO3P123CA0009.outlook.office365.com (2603:10a6:600:ba::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5966.18 via Frontend Transport; Thu, 29 Dec 2022 14:23:34 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 178.79.136.144) smtp.mailfrom=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org;dmarc=pass action=none header.from=masteringemacs.org; Received-SPF: Pass (protection.outlook.com: domain of masteringemacs.org designates 178.79.136.144 as permitted sender) receiver=protection.outlook.com; client-ip=178.79.136.144; helo=semantical.co.uk; pr=C Received: from semantical.co.uk (178.79.136.144) by LO2GBR01FT022.mail.protection.outlook.com (10.152.42.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5966.17 via Frontend Transport; Thu, 29 Dec 2022 14:23:34 +0000 Received: by semantical.co.uk (Postfix, from userid 5001) id A7C08114002; Thu, 29 Dec 2022 14:23:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=masteringemacs.org; s=masteringemacs.org; t=1672323813; bh=RqBFWT8qXBQcult6e8CTjP13UTaos+m4qQ2HRVfliLg=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=Xyv8oqduLrq6YFAv/bTc81e2Be0MwppRO9Jo/F/Peol71n1GpdHhIFdTBFVtr0IXP jjbyrJtQRMKVE2Ff7ma3aYhKR8tFeQcQuNXmfSIxk5Mr2fNOPC2CE78FhzIZsWTH4J QtG28SA8sqN724I3sSFOjUTavFqzBOhK2Z7Ehfv0= X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on semantical.co.uk X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 References: <8A17A5F6-D286-4C3B-9ACB-1751ADE21AB8@gmail.com> User-agent: mu4e @VERSION@; emacs 30.0.50 From: Mickey Petersen To: Yuan Fu Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Date: Thu, 29 Dec 2022 14:21:35 +0000 Organization: Mastering Emacs In-reply-to: <8A17A5F6-D286-4C3B-9ACB-1751ADE21AB8@gmail.com> Message-ID: <87fscye1b2.fsf@masteringemacs.org> Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LO2GBR01FT022:EE_|LO0P265MB6320:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8f270fe6-9aac-4e2f-9aa3-08dae9a844a5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lFE36HYqDDqqKqET8aLgq0jAPjjWg5mOYjkcB79HDcnDlt7KAvKv+ol29l9AhTbASuFTwXmOJN6SqE0jdj1s0zi3BcORJfUeL+Z/cN4UxC1o42xrKRV0ClgHfgT/gMZj5+vfupUJGY7kzn3LS2eR2Z5ABWBUV50Q5l0DVRdcneyHdZPKIVuTcuIej5CcbRJxf/tqpsQXM8mbM/YMtX168CUod5mqcsmzHTEC+Ds2mhKCvh7zRqMmT4jUrMPaQ0XgqC1xiTzXV/YDIOsPClIiEju06gQbZGB6dLJ8tpbARMOkL2H04Zei20dZ05o9ahiH33ja6XnQOhf1QwvdB2HvJ4oizHrJKht93tALjfisS7ti9Za3SQxQ6yIfIAX8L2kmnunQ1LUV0IDcYE1Eow7Iv7/Fksbyw1YJoq4v+t/Z4uhv3Ft1UEeU4UwJ5QMNxTWoX7xE6jwtbKbrVOH6nzJ6q44NW+vb/kFXlKE7WMRSpfYahws9YH9CIBfaqgODNgJggamCDOPXmyfH7zXZlaa/lpviYgfbb6EftU+n41CqcqxNw7ZKSfHJB8KBlzvxzXE9rHXiWkBEFDnIdbE5kawxAIbyQUt0lW0NbEAB7Fi1qzdvUZ4CBUQNSH8GO/mY+rAkCWq1t3nuf5jlFt3jTzd2OPGVc2y02txtrOLERc1QS01W+F653EuoHqCiCCRLe4HbNScpOld9J4cuReieIk8sEYTB0B7UVRwuRQE/xbk/Nid6iQwtMAjtPhSWclGZgSZh X-Forefront-Antispam-Report: CIP:178.79.136.144; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:semantical.co.uk; PTR:semantical.co.uk; CAT:NONE; SFS:(13230022)(39830400003)(396003)(376002)(346002)(136003)(451199015)(36840700001)(46966006)(7636003)(7596003)(356005)(86362001)(8676002)(41300700001)(4326008)(70586007)(316002)(36916002)(42186006)(36860700001)(70206006)(40480700001)(2906002)(6862004)(8936002)(5660300002)(82310400005)(186003)(2616005)(26005)(6266002)(478600001)(336012)(47076005)(36756003)(38230200001)(79816003)(14776008); DIR:OUT; SFP:1102; X-OriginatorOrg: masteringemacs.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Dec 2022 14:23:34.1515 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8f270fe6-9aac-4e2f-9aa3-08dae9a844a5 X-MS-Exchange-CrossTenant-Id: a4e27e3d-bab0-45e8-8942-e64cf9fbd34f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a4e27e3d-bab0-45e8-8942-e64cf9fbd34f; Ip=[178.79.136.144]; Helo=[semantical.co.uk] X-MS-Exchange-CrossTenant-AuthSource: LO2GBR01FT022.eop-gbr01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO0P265MB6320 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Eli Zaretskii , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Yuan Fu writes: > Eli Zaretskii writes: > >>> From: Mickey Petersen >>> Date: Wed, 21 Dec 2022 12:24:34 +0000 >> >> Yuan, can you look into this? The crash is in tree-sitter, so maybe >> it isn't our bug, but I'd like to be sure. And even if it is a >> tree-sitter bug, maybe we can work around it to prevent Emacs from >> crashing? > > Absolutely. > >>> Happens in emacs -Q (after loading some simple elisp code that uses treesit.el) and consistently and repeatedly. >>> >>> >>> Here's the elisp. When I edebug it I can step and view all the >>> variables and expressions I like. The `combobulate-' functions are >>> widely used in the library and pose no issues anywhere else and do >>> nothing more than fetch nodes via tree sitter. It is only this bit of >>> code that blows up, and then only when invoked inside a python >>> string. > > It would be nice if you can make a reproduce recipe. Judging from the > backtrace, you can probably trigger it by printing the node with print > or princ. And does it trigger on all python strings? Or some specific > string in some specific python source? > This issue seems entirely related to `M-x treesit-explore-mode` (and possibly the inspect variant also) though it is hard to reproduce reliably. I get either crashes or hangs, depending on whether I have edebug on or not. Thrown errors seem to be the common denominator? > Yuan From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 18:22:20 2023 Received: (at 60237) by debbugs.gnu.org; 24 Feb 2023 23:22:20 +0000 Received: from localhost ([127.0.0.1]:38563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVhON-00080Y-AU for submit@debbugs.gnu.org; Fri, 24 Feb 2023 18:22:20 -0500 Received: from mail-pj1-f47.google.com ([209.85.216.47]:51767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVhOL-00080M-Q1 for 60237@debbugs.gnu.org; Fri, 24 Feb 2023 18:22:18 -0500 Received: by mail-pj1-f47.google.com with SMTP id kb15so668108pjb.1 for <60237@debbugs.gnu.org>; Fri, 24 Feb 2023 15:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=ZMSVrUJ+mbg9L+kvPr0HwjbpKoEAy/Z9h2K+h/gmxS4=; b=a7QTuFc8AZpVw3ald2CmVApc0+F2yjebEaCYdIj+Uo3+tgiRnFoyWY1/CAkYlVUQon UYfcwcNiIKJgLZqytWe1T5EYqkTcP+InCiSw8NN/3CtLqb5b2KhRy8iqw8e04Bsf1bv1 Ffq8WCSVE6KK9DuQZujlF40NYAhpBW6NrbxJplAoccySK4XxkQuPt+nqqjsOpLp+z5X2 tY38SuJNXZ9l5AbPzNgEgxmKlo3NqI6jJENSHD9yNGsJDfOticRRjwV9XjdqoU6MpcaH 7mUqhpv6qfg6R73CIjrN32gq+j52LaMR8PyOunlp0BMN1uUcBNbsw+Jx9SsyZqkryhs1 D4+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZMSVrUJ+mbg9L+kvPr0HwjbpKoEAy/Z9h2K+h/gmxS4=; b=P9uCcay1KDBRTFSVkPtRdywAjf9xzkYTomPAyK1Sg7La9MFNV9bR0aKdKiemKGYbnM VEArwo2qA6cpeSJ2660X2xFJr2OgQMhThrYQSDUc5e9jq1hpzQoj6YUlv1t5WX3PDNz+ /mVnxO+HvR9YNl/qge56/rmfMpl++MGzH8msWdw6iuJRRc4JocYvOjhPY25x/ErdltZN HwyBaMwZoX8MGAl8TrJMv/5bh4CXRTmJxO8KXXmpnVtqfrLxEVLRT/1jGQ7NBaNZbRRf p8kFkW2nd7RQOb8KdHePX6FEKOupUNB4b7knNb3JtUV4+5YYDMvl6vaFU/a2afYDp2Jt dLhw== X-Gm-Message-State: AO0yUKUPbko2OdTfXl9QGA+UToGDMyUxpBJ601ewgT4mi99Hf2djQTfn klgPukAzyQvHfKE0d+hJnag= X-Google-Smtp-Source: AK7set/Ddm5Dtp8ywQwwnEX2uf9u0HTalT+TRL76BmU4L01o0Cdg4GggR54Mrraz4yCZKdFajAcIJg== X-Received: by 2002:a05:6a21:99a2:b0:a5:df86:f0e1 with SMTP id ve34-20020a056a2199a200b000a5df86f0e1mr1503343pzb.16.1677280931556; Fri, 24 Feb 2023 15:22:11 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id v20-20020aa78514000000b00592eb6f239fsm94755pfn.40.2023.02.24.15.22.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2023 15:22:11 -0800 (PST) From: Yuan Fu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Message-Id: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> Date: Fri, 24 Feb 2023 15:22:00 -0800 To: Mickey Petersen X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: eliz@gnu.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Mickey Petersen writes: > Yuan Fu writes: > >> Eli Zaretskii writes: >> >>>> From: Mickey Petersen >>>> Date: Wed, 21 Dec 2022 12:24:34 +0000 >>> >>> Yuan, can you look into this? The crash is in tree-sitter, so maybe >>> it isn't our bug, but I'd like to be sure. And even if it is a >>> tree-sitter bug, maybe we can work around it to prevent Emacs from >>> crashing? >> >> Absolutely. >> >>>> Happens in emacs -Q (after loading some simple elisp code that uses = treesit.el) and consistently and repeatedly. >>>> >>>> >>>> Here's the elisp. When I edebug it I can step and view all the >>>> variables and expressions I like. The `combobulate-' functions are >>>> widely used in the library and pose no issues anywhere else and do >>>> nothing more than fetch nodes via tree sitter. It is only this bit = of >>>> code that blows up, and then only when invoked inside a python >>>> string. >> >> It would be nice if you can make a reproduce recipe. Judging from the >> backtrace, you can probably trigger it by printing the node with = print >> or princ. And does it trigger on all python strings? Or some = specific >> string in some specific python source? >> > > This issue seems entirely related to `M-x treesit-explore-mode` (and > possibly the inspect variant also) though it is hard to reproduce > reliably. I get either crashes or hangs, depending on whether I have > edebug on or not. > > Thrown errors seem to be the common denominator? I=E2=80=99m 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=E2=80=99t run that session under lldb. Anyway, we can focus on the = crash first. Below=E2=80=99s the backtrace. Eli, could you see anything from this? I = have the lldb session live so let me know if you want to see anything. Unfortunately I can=E2=80=99t get gdb to work on Mac. 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. * thread #1, queue =3D 'com.apple.main-thread', stop reason =3D = EXC_BAD_INSTRUCTION (code=3DEXC_I386_INVOP, subcode=3D0x0) frame #0: 0x0000000100250f3d emacs`ASIZE(array=3D0x00000001a1889245) = at lisp.h:1768:3 1765 ASIZE (Lisp_Object array) 1766 { 1767 ptrdiff_t size =3D XVECTOR (array)->header.size; -> 1768 eassume (0 <=3D size); 1769 return size; 1770 } 1771 Target 0: (emacs) stopped. (lldb) bt * thread #1, queue =3D 'com.apple.main-thread', stop reason =3D = EXC_BAD_INSTRUCTION (code=3DEXC_I386_INVOP, subcode=3D0x0) * frame #0: 0x0000000100250f3d emacs`ASIZE(array=3D0x00000001a1889245) = at lisp.h:1768:3 frame #1: 0x0000000100250e5e = emacs`get_backtrace(array=3D0x00000001a1889245) at eval.c:4193:28 frame #2: 0x00000001003001ce = emacs`record_backtrace(log=3D0x00000001a1887d68, count=3D64) at = profiler.c:162:3 frame #3: 0x000000010030016d emacs`malloc_probe(size=3D64) at = profiler.c:509:3 frame #4: 0x0000000100204e6d emacs`xmalloc(size=3D64) 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=3D0x00000001a2c0f0e0) at = treesit.c:1182:3 frame #8: 0x0000000100212c1b = emacs`cleanup_vector(vector=3D0x00000001a2c0f0e0) at alloc.c:3179:5 frame #9: 0x00000001002124c9 emacs`sweep_vectors at alloc.c:3254:5 frame #10: 0x000000010020c777 emacs`gc_sweep at alloc.c:7430:3 frame #11: 0x000000010020bb67 emacs`garbage_collect at = alloc.c:6262:3 frame #12: 0x000000010020b706 emacs`maybe_garbage_collect at = alloc.c:6107:5 frame #13: 0x00000001002b4bea emacs`maybe_gc at lisp.h:5591:5 frame #14: 0x00000001002afcaa = emacs`exec_byte_code(fun=3D0x0000000107557b85, args_template=3D256, = nargs=3D1, args=3D0x000000010809e338) at bytecode.c:782:6 frame #15: 0x0000000100251e77 = emacs`fetch_and_exec_byte_code(fun=3D0x00000001a1396be5, = args_template=3D514, nargs=3D2, args=3D0x00007ff7bfefc628) at = eval.c:3081:10 frame #16: 0x000000010024e7c1 = emacs`funcall_lambda(fun=3D0x00000001a1396be5, nargs=3D2, = arg_vector=3D0x00007ff7bfefc628) at eval.c:3153:9 frame #17: 0x000000010024e0a7 = emacs`funcall_general(fun=3D0x00000001a1396be5, numargs=3D2, = args=3D0x00007ff7bfefc628) at eval.c:2945:12 frame #18: 0x00000001002494b4 emacs`Ffuncall(nargs=3D3, = args=3D0x00007ff7bfefc620) at eval.c:2995:21 frame #19: 0x000000010024d61c emacs`Fapply(nargs=3D2, = args=3D0x00007ff7bfefc738) at eval.c:2666:24 frame #20: 0x0000000100245752 emacs`apply1(fn=3D0x00000000a0a4d740, = arg=3D0x00000001a38c59b3) at eval.c:2882:43 frame #21: 0x00000001002cb671 = emacs`read_process_output_call(fun_and_args=3D0x00000001a38c59c3) at = process.c:6070:10 frame #22: 0x000000010024a493 = emacs`internal_condition_case_1(bfun=3D(emacs`read_process_output_call = at process.c:6069), arg=3D0x00000001a38c59c3, = handlers=3D0x0000000000000090, = hfun=3D(emacs`read_process_output_error_handler at process.c:6075)) at = eval.c:1498:25 frame #23: 0x00000001002cb5c3 = emacs`read_and_dispose_of_process_output(p=3D0x00000001a1448440, = chars=3D"Content-Length: = 1184\r\n\r\n{\"jsonrpc\":\"2.0\",\"method\":\"textDocument/publishDiagnost= ics\",\"params\":{\"uri\":\"file:///Users/yuan/t/js/test.ts\",\"diagnostic= s\":[{\"range\":{\"start\":{\"line\":4,\"character\":11},\"end\":{\"line\"= :4,\"character\":14}},\"message\":\"Property 'get' does not exist on = type = 'Document'.\",\"severity\":1,\"code\":2339,\"source\":\"typescript\",\"tag= s\":[]},{\"range\":{\"start\":{\"line\":0,\"character\":14},\"end\":{\"lin= e\":0,\"character\":15}},\"message\":\"Parameter 'a' implicitly has an = 'any' type, but a better type may be inferred from = usage.\",\"severity\":4,\"code\":7044,\"source\":\"typescript\",\"tags\":[= ]},{\"range\":{\"start\":{\"line\":0,\"character\":14},\"end\":{\"line\":0= ,\"character\":15}},\"message\":\"'a' is declared but its value is never = read.\",\"severity\":4,\"code\":6133,\"source\":\"typescript\",\"tags\":[1= ]},{\"range\":{\"start\":{\"line\":0,\"character\":17},\"end\":{\"line\":0= ,\"character\":18}},\"message\":\"Parameter 'b' implicitly has an 'any' = type, but a better type may be inferred from = usage.\",\"severity\":4,\"code\":7044,\"source\":\"typescript\",\"tags\":[= ]},{\"range\":{\""..., nbytes=3D1208, coding=3D0x00000001577aed10) at = process.c:6294:5 frame #24: 0x00000001002c46df = emacs`read_process_output(proc=3D0x00000001a1448445, channel=3D26) at = process.c:6204:3 frame #25: 0x00000001002c3097 = emacs`wait_reading_process_output(time_limit=3D5, nsecs=3D0, = read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=3D0x0000000000000000, = wait_proc=3D0x0000000000000000, just_wait_proc=3D0) at process.c:5888:16 frame #26: 0x000000010000c881 = emacs`sit_for(timeout=3D0x0000000000000016, reading=3Dtrue, = display_option=3D1) at dispnew.c:6256:7 frame #27: 0x0000000100166ffd emacs`read_char(commandflag=3D1, = map=3D0x0000000193762fb3, prev_event=3D0x0000000000000000, = used_mouse_menu=3D0x00007ff7bfefeb1f, end_time=3D0x0000000000000000) at = keyboard.c:2872:11 frame #28: 0x0000000100162e18 = emacs`read_key_sequence(keybuf=3D0x00007ff7bfefee40, = prompt=3D0x0000000000000000, dont_downcase_last=3Dfalse, = can_return_switch_frame=3Dtrue, fix_current_buffer=3Dtrue, = prevent_redisplay=3Dfalse) at keyboard.c:10074:12 frame #29: 0x00000001001611c0 emacs`command_loop_1 at = keyboard.c:1375:15 frame #30: 0x000000010024a3c8 = emacs`internal_condition_case(bfun=3D(emacs`command_loop_1 at = keyboard.c:1269), handlers=3D0x0000000000000090, hfun=3D(emacs`cmd_error = at keyboard.c:927)) at eval.c:1474:25 frame #31: 0x0000000100160c63 = emacs`command_loop_2(handlers=3D0x0000000000000090) at = keyboard.c:1124:11 frame #32: 0x0000000100249b53 = emacs`internal_catch(tag=3D0x000000000000f3f0, = func=3D(emacs`command_loop_2 at keyboard.c:1120), = arg=3D0x0000000000000090) at eval.c:1197:25 frame #33: 0x000000010015ffda emacs`command_loop at = keyboard.c:1102:2 frame #34: 0x000000010015fddf emacs`recursive_edit_1 at = keyboard.c:711:9 frame #35: 0x0000000100160352 emacs`Frecursive_edit at = keyboard.c:794:3 frame #36: 0x000000010015d177 emacs`main(argc=3D1, = argv=3D0x00007ff7bfeff6a8) at emacs.c:2529:3 frame #37: 0x00007ff81a314310 dyld`start + 2432 (lldb) up 4 frame #4: 0x0000000100204e6d emacs`xmalloc(size=3D64) at alloc.c:760:3 757 758 if (!val) 759 memory_full (size); -> 760 MALLOC_PROBE (size); 761 return val; 762 } 763 (lldb) list 764 /* Like the above, but zeroes out the memory just allocated. */ 765 766 void * 767 xzalloc (size_t size) 768 { 769 void *val; 770 (lldb) up frame #5: 0x0000000100e6c0c9 libtree-sitter.0.dylib`ts_subtree_release + = 158 libtree-sitter.0.dylib`ts_subtree_release: -> 0x100e6c0c9 <+158>: movq -0x30(%rbp), %rdi 0x100e6c0cd <+162>: movq %rax, 0x10(%rdi) 0x100e6c0d1 <+166>: movl %r15d, 0x1c(%rdi) 0x100e6c0d5 <+170>: movl 0x18(%rdi), %eax (lldb) down frame #4: 0x0000000100204e6d emacs`xmalloc(size=3D64) at alloc.c:760:3 757 758 if (!val) 759 memory_full (size); -> 760 MALLOC_PROBE (size); 761 return val; 762 } 763 (lldb) down frame #3: 0x000000010030016d emacs`malloc_probe(size=3D64) at = profiler.c:509:3 506 malloc_probe (size_t size) 507 { 508 eassert (HASH_TABLE_P (memory_log)); -> 509 record_backtrace (XHASH_TABLE (memory_log), min (size, = MOST_POSITIVE_FIXNUM)); 510 } 511 512 DEFUN ("function-equal", Ffunction_equal, Sfunction_equal, 2, 2, = 0, (lldb) down frame #2: 0x00000001003001ce = emacs`record_backtrace(log=3D0x00000001a1887d68, count=3D64) at = profiler.c:162:3 159 /* Get a "working memory" vector. */ 160 Lisp_Object backtrace =3D HASH_VALUE (log, index); 161 eassert (BASE_EQ (Qunbound, HASH_KEY (log, index))); -> 162 get_backtrace (backtrace); 163 164 { /* We basically do a `gethash+puthash' here, except that we = have to be 165 careful to avoid memory allocation since we're in a = signal (lldb) down frame #1: 0x0000000100250e5e = emacs`get_backtrace(array=3D0x00000001a1889245) at eval.c:4193:28 4190 get_backtrace (Lisp_Object array) 4191 { 4192 union specbinding *pdl =3D backtrace_next (backtrace_top ()); -> 4193 ptrdiff_t i =3D 0, asize =3D ASIZE (array); 4194 4195 /* Copy the backtrace contents into working memory. */ 4196 for (; i < asize; i++) (lldb) down frame #0: 0x0000000100250f3d emacs`ASIZE(array=3D0x00000001a1889245) at = lisp.h:1768:3 1765 ASIZE (Lisp_Object array) 1766 { 1767 ptrdiff_t size =3D XVECTOR (array)->header.size; -> 1768 eassume (0 <=3D size); 1769 return size; 1770 } 1771 (lldb) p size (ptrdiff_t) $0 =3D -9223372036854775792 (lldb) p XVECTOR(array) (Lisp_Vector *) $1 =3D 0x00000001a1889240 (lldb) p XVECTOR(array)->header (vectorlike_header) $2 =3D (size =3D -9223372036854775792) (lldb) p *array error: expression failed to parse: error: :1:1: incomplete type 'Lisp_X' where a = complete type is required *array ^ (lldb) From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 18:29:34 2023 Received: (at 60237) by debbugs.gnu.org; 24 Feb 2023 23:29:34 +0000 Received: from localhost ([127.0.0.1]:38572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVhVO-0008Ct-0r for submit@debbugs.gnu.org; Fri, 24 Feb 2023 18:29:34 -0500 Received: from mail-pj1-f50.google.com ([209.85.216.50]:34445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVhVM-0008Cf-Ji for 60237@debbugs.gnu.org; Fri, 24 Feb 2023 18:29:33 -0500 Received: by mail-pj1-f50.google.com with SMTP id x20-20020a17090a8a9400b00233ba727724so7212204pjn.1 for <60237@debbugs.gnu.org>; Fri, 24 Feb 2023 15:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=bv+Jetg+PUnwRaZ8xjoHHeS8RchY4B7a1qNuWy3Nkmk=; b=hBlF+UEX9qiNjjdCi5eAsfY723jEXeAHazmQ+uj7wm5ARUDGLMTDaPntQxBO0AaTBG 7otUy5j44QPGrhsh+Hptik/01UrG2B44JwDSRCuV84OlhbU0EjRfamn0rg6DyecKCZlt a+EZm1EqiJNBxunHEJfN5fPUuiZvwyMNMn+CpZT9oSyktvRa9eauIltf/1YRA5HXI/W3 3vacqHIUHzlSFvHwL5UUiMerOhyNxAmfU5QUQuVc6cDFrjspb0+hlAfWZtqvSOWFYiq+ 8qxys3fovnsTEx90O+7xbS2Fdh5QorNJN1TyZdPsUe73mPcoov9W9Lol8WOp+1KpSkcy 81iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bv+Jetg+PUnwRaZ8xjoHHeS8RchY4B7a1qNuWy3Nkmk=; b=34wNrynV+qln96V3Zj756AutZvKbpV7SJad/3A9mFWhWATZyne/kITnW3yUfu8OXvh 7NUpzXHKOoeZCH7Q5PVkAnADPi6AZu4wt/vWWyJsFdjK6Kq6BUzJdqlQ/VU9mkUyEK2C i7DZiJa3Yz///Y32cm6O55h5I5GXmMxGXROLZpm/klCTUr2lksgvt7PApoFQHwWJdbxs TcqNordsERjoZqlfXJ2GBwvNZm4RpQLYWXX40V2PuhFh1IbFWrCfUOQXtJJFQFK+Qx9x F2XJ3SfD45hJPoMJ3TWJvfD4sfzGAtjn4agg5YDYq6jJbi39jafF6dXG9m5BXlUozCNc /tlA== X-Gm-Message-State: AO0yUKV47g92QxA8R7vWRyYVSvxZZwPHmteAyjXkgdASBcb0JkidKweq y1+I/ERn6iUy/mrAfvFcUG0= X-Google-Smtp-Source: AK7set93GE5DQ7jpAtLHm6zlMyAxTUl0haNS39Rc7kEihwisMTh5wdSKUxxWVsnr7EHMV181Fys5mw== X-Received: by 2002:a17:903:5c4:b0:19c:9999:e92e with SMTP id kf4-20020a17090305c400b0019c9999e92emr11453008plb.23.1677281366637; Fri, 24 Feb 2023 15:29:26 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id x24-20020a63db58000000b004fb71d96d78sm49188pgi.2.2023.02.24.15.29.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2023 15:29:26 -0800 (PST) From: Yuan Fu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Message-Id: <9310F6C6-8B17-41D5-BF5D-E116910D646E@gmail.com> Date: Fri, 24 Feb 2023 15:29:15 -0800 To: Mickey Petersen X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: eliz@gnu.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Yuan Fu writes: > Mickey Petersen writes: > >> Yuan Fu writes: >> >>> Eli Zaretskii writes: >>> >>>>> From: Mickey Petersen >>>>> Date: Wed, 21 Dec 2022 12:24:34 +0000 >>>> >>>> Yuan, can you look into this? The crash is in tree-sitter, so = maybe >>>> it isn't our bug, but I'd like to be sure. And even if it is a >>>> tree-sitter bug, maybe we can work around it to prevent Emacs from >>>> crashing? >>> >>> Absolutely. >>> >>>>> Happens in emacs -Q (after loading some simple elisp code that = uses treesit.el) and consistently and repeatedly. >>>>> >>>>> >>>>> Here's the elisp. When I edebug it I can step and view all the >>>>> variables and expressions I like. The `combobulate-' functions are >>>>> widely used in the library and pose no issues anywhere else and do >>>>> nothing more than fetch nodes via tree sitter. It is only this bit = of >>>>> code that blows up, and then only when invoked inside a python >>>>> string. >>> >>> It would be nice if you can make a reproduce recipe. Judging from = the >>> backtrace, you can probably trigger it by printing the node with = print >>> or princ. And does it trigger on all python strings? Or some = specific >>> string in some specific python source? >>> >> >> This issue seems entirely related to `M-x treesit-explore-mode` (and >> possibly the inspect variant also) though it is hard to reproduce >> reliably. I get either crashes or hangs, depending on whether I have >> edebug on or not. >> >> Thrown errors seem to be the common denominator? > > I=E2=80=99m 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=E2=80=99t run that session under lldb. Anyway, we can focus on = the crash > first. Maybe it will help us understand the problem better, so here is the backtrace for the infinite loop. I=E2=80=99m not sure why = treesit_delete_parser would trigger gc, as it just calls two tree_sitter functions: void treesit_delete_parser (struct Lisp_TS_Parser *lisp_parser) { ts_tree_delete (lisp_parser->tree); ts_parser_delete (lisp_parser->parser); } Date/Time: 2023-02-24 15:08:13.620 -0800 End time: 2023-02-24 15:09:53.381 -0800 OS Version: macOS 13.2.1 (Build 22D68) Architecture: x86_64h Report Version: 40 Incident Identifier: B9F9C8A6-5293-4B70-935A-FAB1EF623EB2 Data Source: Stackshots Shared Cache: 57815A20-AF2C-3B56-9006-23ABDE7962B0 slid base address = 0x7ff81a27a000, slide 0x1a27a000 (System Primary) Shared Cache: E1E267C5-FE0B-3ED9-86BE-E4F329F01460 slid base address = 0x7ff818076000, slide 0x18076000 (DriverKit) Command: emacs Path: /Users/USER/*/emacs Architecture: x86_64 Parent: fish [11593] [unique pid 110818] Responsible: iTerm2 [1312] PID: 11610 Time Since Fork: 186s Event: hang Duration: 99.76s Duration Sampled: 4.20s (process was unresponsive for 96 seconds before = sampling) Steps: 42 (100ms sampling interval) Hardware model: MacBookPro16,3 Active cpus: 8 HW page size: 4096 VM page size: 4096 Time Since Boot: 259463s Time Awake Since Boot: 136664s Time Since Wake: 1506s Fan speed: 4411 rpm -> 4591 (+180) Total CPU Time: 8.453s (31.1G cycles, 29.7G instructions, 1.05c/i) Advisory levels: Battery -> 3, User -> 2, ThermalPressure -> 1, = Combined -> 2 Free disk space: 65.61 GB/465.63 GB, low space threshold 3072 MB Vnodes Available: 73.05% (192242/263168) Preferred User Language: en-US, zh-Hans-US Country Code: US Keyboards: ABC OS Cryptex File Extents: 2417 -------------------------------------------------- Timeline format: stacks are sorted chronologically Use -i and -heavy to re-report with count sorting -------------------------------------------------- Heaviest stack for the main thread of the target process: 42 start + 2432 (dyld + 25360) [0x7ff81a314310] 42 main + 7399 (emacs.c:2529,3 in emacs + 1429879) [0x10fc30177] 42 Frecursive_edit + 306 (keyboard.c:794,3 in emacs + 1442642) = [0x10fc33352] 42 recursive_edit_1 + 255 (keyboard.c:711,9 in emacs + 1441247) = [0x10fc32ddf] 42 command_loop + 282 (keyboard.c:1102,2 in emacs + 1441754) = [0x10fc32fda] 42 internal_catch + 67 (eval.c:1197,25 in emacs + 2399059) = [0x10fd1cb53] 42 command_loop_2 + 35 (keyboard.c:1124,11 in emacs + 1444963) = [0x10fc33c63] 42 internal_condition_case + 136 (eval.c:1474,25 in emacs + 2401224) = [0x10fd1d3c8] 42 command_loop_1 + 2627 (keyboard.c:1494,13 in emacs + 1447651) = [0x10fc346e3] 42 call1 + 60 (lisp.h:3247,10 in emacs + 1464844) [0x10fc38a0c] 42 Ffuncall + 324 (eval.c:2995,21 in emacs + 2397364) [0x10fd1c4b4] 42 funcall_general + 279 (eval.c:2945,12 in emacs + 2416807) = [0x10fd210a7] 42 funcall_lambda + 385 (eval.c:3153,9 in emacs + 2418625) = [0x10fd217c1] 42 fetch_and_exec_byte_code + 87 (eval.c:3081,10 in emacs + 2432631) = [0x10fd24e77] 42 exec_byte_code + 3739 (bytecode.c:809,14 in emacs + 2817595) = [0x10fd82e3b] 42 funcall_subr + 401 (eval.c:3038,15 in emacs + 2417601) = [0x10fd213c1] 42 Fcall_interactively + 1057 (callint.c:342,36 in emacs + 2363633) = [0x10fd140f1] 42 Fapply + 2348 (eval.c:2666,24 in emacs + 2414108) [0x10fd2061c] 42 Ffuncall + 324 (eval.c:2995,21 in emacs + 2397364) [0x10fd1c4b4] 42 funcall_general + 197 (eval.c:2941,12 in emacs + 2416725) = [0x10fd21055] 42 funcall_subr + 810 (eval.c:3059,9 in emacs + 2418010) = [0x10fd2155a] 42 Ffuncall_interactively + 47 (callint.c:250,32 in emacs + 2362479) = [0x10fd13c6f] 42 Ffuncall + 324 (eval.c:2995,21 in emacs + 2397364) [0x10fd1c4b4] 42 funcall_general + 279 (eval.c:2945,12 in emacs + 2416807) = [0x10fd210a7] 42 funcall_lambda + 385 (eval.c:3153,9 in emacs + 2418625) = [0x10fd217c1] 42 fetch_and_exec_byte_code + 87 (eval.c:3081,10 in emacs + 2432631) = [0x10fd24e77] 42 exec_byte_code + 3338 (bytecode.c:782,6 in emacs + 2817194) = [0x10fd82caa] 42 maybe_gc + 26 (lisp.h:5591,5 in emacs + 2837482) [0x10fd87bea] 42 maybe_garbage_collect + 38 (alloc.c:6107,5 in emacs + 2144006) = [0x10fcde706] 42 garbage_collect + 999 (alloc.c:6262,3 in emacs + 2145127) = [0x10fcdeb67] 42 gc_sweep + 39 (alloc.c:7430,3 in emacs + 2148215) [0x10fcdf777] 42 sweep_vectors + 297 (alloc.c:3254,5 in emacs + 2172105) = [0x10fce54c9] 42 cleanup_vector + 523 (alloc.c:3179,5 in emacs + 2173979) = [0x10fce5c1b] 42 treesit_delete_parser + 25 (treesit.c:1182,3 in emacs + 3175289) = [0x10fdda379] 42 ts_tree_delete + 44 (libtree-sitter.0.0.dylib + 114692) = [0x110942004] 42 ts_subtree_release + 158 (libtree-sitter.0.0.dylib + 102601) = [0x11093f0c9] 42 xmalloc + 77 (alloc.c:760,3 in emacs + 2117229) [0x10fcd7e6d] 42 malloc_probe + 93 (profiler.c:509,3 in emacs + 3146093) = [0x10fdd316d] 42 record_backtrace + 95 (profiler.c:169,19 in emacs + 3146207) = [0x10fdd31df] 42 hash_lookup + 90 (fns.c:4693,44 in emacs + 2505546) [0x10fd36b4a] 42 ??? [0x7fa1909ed180] 42 _sigtramp + 29 (libsystem_platform.dylib + 15389) [0x7ff81a671c1d] 42 deliver_fatal_thread_signal + 26 (sysdep.c:1795,3 in emacs + = 1650762) [0x10fc6604a] 42 deliver_thread_signal + 137 (sysdep.c:1775,3 in emacs + 1662777) = [0x10fc68f39] 42 handle_fatal_signal + 24 (sysdep.c:1783,3 in emacs + 1662632) = [0x10fc68ea8] 42 terminate_due_to_signal + 192 (emacs.c:447,11 in emacs + 3863584) = [0x10fe82420] 42 shut_down_emacs + 489 (emacs.c:2991,3 in emacs + 1422313) = [0x10fc2e3e9] 42 Fdo_auto_save + 309 (fileio.c:6042,18 in emacs + 1894389) = [0x10fca17f5] 42 Fexpand_file_name + 110 (fileio.c:956,13 in emacs + 1841918) = [0x10fc94afe] 42 Ffind_file_name_handler + 331 (fileio.c:324,24 in emacs + 1830395) = [0x10fc91dfb] 42 fast_string_match + 55 (lisp.h:4768,10 in emacs + 1831287) = [0x10fc92177] 42 fast_string_match_internal + 94 (search.c:487,7 in emacs + = 1988174) [0x10fcb864e] 42 compile_pattern + 599 (search.c:235,4 in emacs + 1988967) = [0x10fcb8967] 42 compile_pattern_1 + 331 (search.c:121,18 in emacs + 2021755) = [0x10fcc097b] 42 rpl_re_compile_pattern + 73 (regex-emacs.c:5170,9 in emacs + = 2062489) [0x10fcca899] 42 regex_compile + 133 (regex-emacs.c:1768,25 in emacs + 2062693) = [0x10fcca965] 42 xmalloc + 77 (alloc.c:760,3 in emacs + 2117229) [0x10fcd7e6d] 42 malloc_probe + 93 (profiler.c:509,3 in emacs + 3146093) = [0x10fdd316d] 42 record_backtrace + 95 (profiler.c:169,19 in emacs + 3146207) = [0x10fdd31df] 42 hash_lookup + 90 (fns.c:4693,44 in emacs + 2505546) [0x10fd36b4a] 42 ASIZE + 45 (lisp.h:1768,3 in emacs + 2442877) [0x10fd2767d] *37 hndl_alltraps + 95 (kernel + 694399) [0xffffff800038587f] *22 user_trap + 1218 (kernel + 2542418) [0xffffff8000548b52] *21 exception_triage_thread + 490 (kernel + 1119322) = [0xffffff80003ed45a] *15 exception_deliver + 2172 (kernel + 1117868) [0xffffff80003eceac] *15 mach_exception_raise + 265 (kernel + 1631513) [0xffffff800046a519] *5 kernel_mach_msg_rpc + 689 (kernel + 1139009) [0xffffff80003f2141] *4 ipc_port_adjust_special_reply_port_locked + 1170 (kernel + 989010) = [0xffffff80003cd752] *2 ipc_port_send_turnstile_complete + 213 (kernel + 989509) = [0xffffff80003cd945] *2 mpsc_daemon_enqueue + 177 (kernel + 1240465) [0xffffff800040ad91] *2 ??? (kernel + 1548050) [0xffffff8000455f12] From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 02:16:15 2023 Received: (at 60237) by debbugs.gnu.org; 25 Feb 2023 07:16:15 +0000 Received: from localhost ([127.0.0.1]:38875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVon1-0002jd-Af for submit@debbugs.gnu.org; Sat, 25 Feb 2023 02:16:15 -0500 Received: from sonic303-47.consmr.mail.ne1.yahoo.com ([66.163.188.173]:38160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVomz-0002jO-Lr for 60237@debbugs.gnu.org; Sat, 25 Feb 2023 02:16:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677309367; bh=+1Bz8zfA6UlS9Jzxs5vSZ6i7EmQnZsgvYVLxc33MQsE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=L/wTLLwq98eNj2wMyx9tUIEPblW2XGobJX8RsDyhYlXQc6ySqYSfLfS7kVX1qYWbY334Hic8Bc/sk9Y4CqrzSrMw9Z8/eatT4afgPXvABrzUad1avTz4pHn8bkIpF27O6MIDlOhL4Ch+5OhsWy6CuaWI8fjRNyUHovO4Tn4h+OT72yZPRWNeRDtOEYkuwuzr+/ZV1RFX7OMCupxs2pB7+bzJnvlRxavGqWHIHbg8VI3X6oQfQ+xK/SkILmLvGPwYjCiip/fMPfQxQKQ7vY3w5R3qGUnES2ejDo4kMp8Dj5xF5mDzcouVPnUVMsw/BJxkwwXYVbqSZkh0FCYr8NPGGA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677309367; bh=mpzoQXIJlq/qlFe4AdSaMWEZgBzqmQ1WYvby8ODyGcy=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=kPk7kyewuTBs+tBemCVDUARD+9ZmW4IHZLM0z7a5QG0C6yOZin7dZaJ+nUOFDUNLDYXznn3YT3ec5iA71yL/71ys3Kn1dQDdjT9I6LTt2U0bn7+oWXXZP1lMh3qBvXuG7SwC+ObkbRDI+1Yphj/BIXIiyqBgAxQnelQfeBbPPoN5+hg22qOYIaflIJlZvX+8Vh6oprs9L0Dtr06tugB0NJ8XOnSHrYknuW8FKGP25WlO7iLCapsBTz4NR1iVaE9GQ8fNRJ8QtUcZ3pvfpMGW2hM8VmYe+C2Lu4/+tyNOd7Klt7cdKpTDmYIu6SwCl2HoS7eXaNhWXHridoAg2RbwVw== X-YMail-OSG: cIO9rK8VM1lkHpLNJYaOnN1k_93sfavy5gzaMgvrFTUrGMLHwX6WJ_mcqnAVpya R3ALLmMGucgsDcN0bM5OkJPGP.KXoI77lat50M.huSCRD5NMHQmh05hTfBbWsaR4pnJCH9E9a1O8 NyGQlj4IGeHsR3319Gp6ci7a9RzucXMkCblUHmWWVE4F7adtuLRFzrSo59pJHaPC1FF2CmDlhRTH .mu4jsnSmjjCF0Qxld.a10dqPOAbtcjP2vh69DSt6_AmDTZGDnV.e6bohhSqteN1f37tpSeoxrHU J9QF8FyniU1TEAcGPICvmGNq1doPjkJTb2JQQxY5sZ3A4L42G1tBrCD1m3eJBgqKzaWh93_MPMmx 5Vh_OMZDr1iM9iaNpKaKKKAfNBkxezuVSq3tMlUySTBUQn4VaQgaaQYbd5A2utxtccIO9uergDEx nYFqgsoU2zzm3vDS4almeaUOEcyeuT8BT0Bg6xTHZKb6uzxY1ztF.g.J504xuB4cIzIzwgYvIv59 ykPKvLKT_G.cHdHXqYN73WQ_bav1mEE1MUgFV9AUWzA1u.9NywbwGmhO0rPVw4BnwJ974xAPUXSS LYUXrdqvnPdL2ipEvuYDon4mgisuKcoAGYo2R0Fq.xO27svn0GCeTxWkZIDfd5TbucvU4jP_TvWb qRlnjtlbzRl138BIF_A4p1MI0oEvehuGVS8RWBAA6GQrO1YO0Fjm3qjns___jr8a8H8ofcaaExBr 3ipSl.IrFwq61eSHMyi535woPN.pfZNUvcy2xTaRGVgRcbNmki3KXFMaCKc.bvztoUegEYH9IXBJ Nne9eXZhN2fjdXGk2ApNuHi6Ve1rEpT8wtkCTBg284y0cxJHAbR32PpyU7RCdMFIFXF3kwvIVWQy U6Phn3s8lAkGFzBW9TnLxT22cOxocVJBin2JZPGFBq2xZWF7HlJAyA8RWxs5SCBC8s8GJwaBz1Py W6zQp3l1Drx_avsU_oIkoOwD5QogqVb_dssRFcxP5mrQ.vxkLCHxLwgvhEcc2OM5orrK6NF2nZPF UWrtQuVJRdM1ddtZYtw3B1bjJnVPXS1RjKG4bv.YH33Q4rBPUTbG0cX0XQ27qmxf.QRuvIWy4_Un mnorzVKaIhSPiADKGsJ8sSD6LlnsHLvSe4hUvoPNZrCtzVv7sCOeDDIp_LV7XHwFfZqFbnCQWPUx UeRVWQJgqwL4snGLIIxsWljJIsfcPZLH8gRhACie47S0yrhG3ROVkuz8bttwHH5MUZyl4gJxFFBo HygzbtqT8.38OSwm.KtlC7D1d0HLH5RawxzgX0o8OvUkya8VHnPnSFBfXW.Jm.7iXlqlGCjFYhy9 O_wyik_fgaym36CoTud.Uz69ZY0vpzdBwt9lQ3iX34gJPJjUvLPPomjJBTVeLzZiWr0sBTDiOdWE 4pmePNA6usGZ.tAtNxjzqfHB.x6o0H3MPqspiNV9lvtrfRwM1c6RRkNh6m_ZiNIAArQdTHLXBMOn z6h6Vrh5REVhlTMGSRoXp4abYyV8qyXMpt0lLUBhv2jfDgTVgDST8hMWgV5imb5xmxiX9t0hFgjU NlTmMG4eT1urDlDa3TDjz6nAdQZ.2ZbRy08jKdA7zb7x6icPAVOFzvczCwgDRru1zrvszWLyS64G KWJvQT6bqA.F3Q3VmfoNO3QpvggQDPOAAe5o2piKqTWB_XipIDbjoz4j54W.LkhTyUCqWrMqnUAM VJ4X3T1tNpS_wFPWlmiH_f2DNkBf1e6T.WrdOr0yfpzEu5Ly8B8cNljHhYzsyNXzL35mAzcldNQx iRnmGQYSHjI8CALML_2pLd6JY5IWPVCg_gxmgwbl8mqJ8PEDHb.fO7hjXk07bM9TVmU40iIZZSJQ 7ECsXy5.oj3A1PygQD1kECVahsGbEuSDDopBLITFJk2Dg17wg0LlmV8FG1Fyxm3jLIEzgiWTR7kK 859VOYusyUSX7KM8.h1FdpEKUt7uS58i9KCZU_0r.ioOJpHUCBMDcarYpXMzRyWZfKgUOxmyki33 2ArYXZDiZrVes.3eGCkBkkUBtrClZwU47Uc0yqMfozGpJ6Qb0B35882w0lNGdU5UkTdvnkLzYRS_ yYD_Xo8Qti0Ri3lrvZfMR7_MTtfjKCpXdVapbEli3fr84LhL62yCBPuRL4W5mZ5tesMnAA5fb9sr CJIGNTq.jaV7tTLPqSD.FM96hgOC_wMhiC8si7CZdsvH_E_eI1I3qEei4NfJzVgskYicrFGdHYrv SU5UdDijcZsUd4l0sswXDehUcvB4k.AczLeJ_EBkcmNAhKt7IqhEZFbdOoWg38dbkEWeE6SqUn1h kSTyaru0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Sat, 25 Feb 2023 07:16:07 +0000 Received: by hermes--production-sg3-9fc5746c8-28mz5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c88e501bdc54bef5386833608372a38f; Sat, 25 Feb 2023 07:14:05 +0000 (UTC) From: Po Lu To: Yuan Fu Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> (Yuan Fu's message of "Fri, 24 Feb 2023 15:22:00 -0800") References: <87o7rx7xml.fsf@masteringemacs.org> <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> Date: Sat, 25 Feb 2023 15:13:44 +0800 Message-ID: <874jra43pz.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21221 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2704 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: eliz@gnu.org, Mickey Petersen , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Yuan Fu writes: > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) > 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 This is a bug inside the profiler: if it is trying to hook into xmalloc, it should not call anything that can call ASIZE, because GC modifies the mark bits inside the vector header, which happen to be stored in the `size' field, and GC has been able to call xmalloc ever since the mark stack stuff was installed. Since you assume 0 <= size, LLVM is generating one of its favorite instructions, ud2, in response to a situation you told the compiler would never happen. Make sure that situation doesn't happen!! > Target 0: (emacs) stopped. > (lldb) bt > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) > * 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 > frame #8: 0x0000000100212c1b emacs`cleanup_vector(vector=0x00000001a2c0f0e0) at alloc.c:3179:5 > frame #9: 0x00000001002124c9 emacs`sweep_vectors at alloc.c:3254:5 > frame #10: 0x000000010020c777 emacs`gc_sweep at alloc.c:7430:3 > frame #11: 0x000000010020bb67 emacs`garbage_collect at alloc.c:6262:3 > frame #12: 0x000000010020b706 emacs`maybe_garbage_collect at alloc.c:6107:5 > frame #13: 0x00000001002b4bea emacs`maybe_gc at lisp.h:5591:5 BTW, where do you see GC being called from treesit_delete_parser? What I see is a bug in the profiler; it should use some other data structure to store its backtraces, when its xmalloc hook is called. 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 02:51:40 2023 Received: (at 60237) by debbugs.gnu.org; 25 Feb 2023 07:51:40 +0000 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 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 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==; 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 Date: Sat, 25 Feb 2023 09:51:32 +0200 Message-Id: <83sfeukwsb.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> (message from Yuan Fu on Fri, 24 Feb 2023 15:22:00 -0800) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 02:55:39 2023 Received: (at 60237) by debbugs.gnu.org; 25 Feb 2023 07:55:39 +0000 Received: from localhost ([127.0.0.1]:38904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVpP8-0003pa-St for submit@debbugs.gnu.org; Sat, 25 Feb 2023 02:55:39 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVpP7-0003pL-5h for 60237@debbugs.gnu.org; Sat, 25 Feb 2023 02:55:37 -0500 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 1pVpP1-0004nn-Uq; Sat, 25 Feb 2023 02:55:31 -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=JbCT8l7/gB0JLC4unQyUGpGrXLS69zo1NrgCyetnXk0=; b=oIDB7Bs/SB/w/wIVTmnH 5KYla30ZuQbuzadwbrlvUpG+CeyGC8fC3dZt9dRweYzpqzky9NNdh8gRM1tQTE+d6ITjUJCLSLHjR sWSB2yIZgtVNZaWuld0IGxW+aAivtVBbmluvfpco6th4ggkvWqjj/cIHtxfhSzFf7VgWQC6iYzoSV AssQwA6RlkqunyCew/euYY4l2FpwsBFHx/D7W4ysJCOKm7R8rxK6MeorQouASrEhiG/oOOy8vxphL S1+Pf/OOshn+TcaxdHtfmyFrOz1+dOFbxqsbnj+Mx5W7PxlgbJKXq3BLPpH+jHrKjJ8KJz1AR/jhU bjEYAMmoLX/IbQ==; 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 1pVpP0-0002js-WF; Sat, 25 Feb 2023 02:55:31 -0500 Date: Sat, 25 Feb 2023 09:55:33 +0200 Message-Id: <83r0uekwlm.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <9310F6C6-8B17-41D5-BF5D-E116910D646E@gmail.com> (message from Yuan Fu on Fri, 24 Feb 2023 15:29:15 -0800) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <9310F6C6-8B17-41D5-BF5D-E116910D646E@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuan Fu > Date: Fri, 24 Feb 2023 15:29:15 -0800 > Cc: eliz@gnu.org, > 60237@debbugs.gnu.org > > Maybe it will help us understand the problem better, so here is the > backtrace for the infinite loop. I’m not sure why treesit_delete_parser > would trigger gc, as it just calls two tree_sitter functions: > > void > treesit_delete_parser (struct Lisp_TS_Parser *lisp_parser) > { > ts_tree_delete (lisp_parser->tree); > ts_parser_delete (lisp_parser->parser); > } According to the backtrace, it's the other way around: Emacs called some function via funcall, and funcall decided it was a good time to do a GC. Then GC called treesit_delete_parser, presumably because that parser object was no longer in use? From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 21:01:27 2023 Received: (at 60237) by debbugs.gnu.org; 26 Feb 2023 02:01:27 +0000 Received: from localhost ([127.0.0.1]:41981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW6Lu-0000ni-Vj for submit@debbugs.gnu.org; Sat, 25 Feb 2023 21:01:27 -0500 Received: from mail-pl1-f182.google.com ([209.85.214.182]:40635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW6Lt-0000nQ-H2 for 60237@debbugs.gnu.org; Sat, 25 Feb 2023 21:01:25 -0500 Received: by mail-pl1-f182.google.com with SMTP id u14so3393732ple.7 for <60237@debbugs.gnu.org>; Sat, 25 Feb 2023 18:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gs6cJGvJITHHOeNTE4ys82ogQBOC6RMcYIzCo76NfAo=; b=YZR499Q6T6+t9Y8LTiml8crkTiMSblKPNLQi920jx0atU7QdQqvFfKxdUi+WXGla2I V/40PTh7PBgHsCDJgHJtx+wc0d/ZURPletGP0nOZziFJ0Ibk5RTfqGh0e16qfVkdnKMr +HTqH8ay2ExfDC/7mGJBXJllDynKAXLG4y/nGqZCB7/LZyEZeOvqewlpYqBrxHoniuPd 9aG/j9jFpoUNUi4ZvsHj/7oei3K7VRa7/MvhHGQF2EUqrfwb8IlmD9+NLiG9Jn0R/XBt 1m71egzDgdYIyyVPtCuM2SJN8SVMh/iHeCz/jnxj9OPE/Wxgz9BijcJGfMejn3K00f36 g5DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gs6cJGvJITHHOeNTE4ys82ogQBOC6RMcYIzCo76NfAo=; b=mXQuFn4ACtbtBfTKTPBo57kI8bdx8vIDfnPP9VcV2gnFBHeDTcbFDf+1JORCm1b2lQ R85jeojOqAl8EqVAsrUwiJowmjEWjlIref2AzHQO1VlOlV+aWTqFaHnY81x+Xref+irq W8i6OVY/W45hjSN6kej5hbLKAl93K52ouag/xXSkT/+ePuDIk6npwFfC2KiXQsRPLlG0 tLg8dXeeJ/mhBVZJmxlmcCErtvL/XORHw+qOjsxJhmEAxWSMpbt55EQqlVpPwhAZhM6r IHhJmvcTxCyq/jmPJ64Q98+l3nnyqz9HSAAbwW0Rfbcz525TQjQWleyP5/RHJlXXJjQY Vd9g== X-Gm-Message-State: AO0yUKUn9vHnGM+gby5u8IBCvpWwEgggOhPpgILnLtsMjecKmb33+LDA 4Oubn9UYaiernzLfDYxqm1o= X-Google-Smtp-Source: AK7set8pWSdWTOWSO54i4klqQChS1xzImIs6IDlpcK1DSLB0AtdArRu7lIxHcUHB5lDwtvD1atNwbg== X-Received: by 2002:a17:902:eccc:b0:19c:eda7:e0fd with SMTP id a12-20020a170902eccc00b0019ceda7e0fdmr4117019plh.59.1677376879570; Sat, 25 Feb 2023 18:01:19 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id e5-20020a170902b78500b0019c922911a2sm1850880pls.40.2023.02.25.18.01.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Feb 2023 18:01:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node From: Yuan Fu In-Reply-To: <83sfeukwsb.fsf@gnu.org> Date: Sat, 25 Feb 2023 18:01:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Po Lu , Mickey Petersen , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 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. >=20 > 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.=20 Therefore, deleting a tree is not simply free(). Instead, you decrement = the refcount of the subtree, and if the count =3D=3D 0, free the data = and traverse the subtree and decrementing each children=E2=80=99s = refcount, and delete them if the count =3D=3D 0, and so on. To traverse = the tree, the function uses an array as a stack, which calls array_push = to push new elements, which may call malloc. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 21:02:19 2023 Received: (at 60237) by debbugs.gnu.org; 26 Feb 2023 02:02:19 +0000 Received: from localhost ([127.0.0.1]:41985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW6Ml-0000pI-Bs for submit@debbugs.gnu.org; Sat, 25 Feb 2023 21:02:19 -0500 Received: from mail-pl1-f172.google.com ([209.85.214.172]:33569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW6Mj-0000p4-8i for 60237@debbugs.gnu.org; Sat, 25 Feb 2023 21:02:17 -0500 Received: by mail-pl1-f172.google.com with SMTP id p6so2554196plf.0 for <60237@debbugs.gnu.org>; Sat, 25 Feb 2023 18:02:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3Hd/7GoS0PscKXMiFACigyxseDyr9VNVIxByVv/W7b8=; b=HXrXRYgRZy7AN6u0ueyMT9kTVPh46CYjC2niKbzqbJV2hDHtVofiIe+t9HE9AX64kI i/UL9Hu5IrcNFDRLOsB+f1HXCYU+l4VNjCUZlKEQpksEDyzG46b1oFeK7Yh+gLgsKcBT 3ri2+9JoX+mIgf6SkIALS0Ks98wz/lNSqSEZgEJ+5oMFXx3ZNew+iiM+uKrR8Zdio7eC TmBbbzTfV4UeTjnOhJK7jNx4Tg0xNhvhzR3bHOvn3pzfypX37K2IA1aAbdtvXR62Rt7I JWNmip+vryzfgNz9VRhE7UuI+SD78yBfb68JhNOxkw0R9K55rlwVEpW99MbaFe3pdSlZ Jl5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3Hd/7GoS0PscKXMiFACigyxseDyr9VNVIxByVv/W7b8=; b=zjN610f4p0+vSskqInzl2xSsWTc5MUS77Ft89whstyZtAmgJY9rIJkaUi6E5JNhKc+ 2WmPIzlU5TUlYFT3BKWMJF/9qjjqY2Hlojatk1TxoAyCWqFKgik+qe4NJ8Y3J9nVcbNh F8LYZhHm2jFw2aDPUrGKHT1SBSZCxpwvy9ih2+yfojZlu4pWcJeGckMe6TclPwjuvHzl XqWPY9yQTYZarFvmBRS6E/yTR19YoLchNg5L6K9hM0Paas9GkjW9w8p42fj+blrpA8lE CoCZ/Jff0mZ+i7pbY5/5yRqclRSVcng6pfeVrIjvEFdR+gqaC+47th8D2Aw3GxRdbZ94 8Jdw== X-Gm-Message-State: AO0yUKXz5AxT3gUk/dRDRD/Y60BpeU3xWp49OhFU/+JmHkbfJSHSQE8A FdC4up/kAri6WBP1AMPARVQsP8cK46rkLg== X-Google-Smtp-Source: AK7set9dl8XEf9nQ2u0lpsZvfMV4Zu0QUwPNpHbjx3FxFU0iU79njxuUw5ODdth+L9h6j1Po8ik9gg== X-Received: by 2002:a17:903:690:b0:19c:bbd3:84b7 with SMTP id ki16-20020a170903069000b0019cbbd384b7mr8863329plb.65.1677376931673; Sat, 25 Feb 2023 18:02:11 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id e5-20020a170902b78500b0019c922911a2sm1850880pls.40.2023.02.25.18.02.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Feb 2023 18:02:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node From: Yuan Fu In-Reply-To: <83r0uekwlm.fsf@gnu.org> Date: Sat, 25 Feb 2023 18:02:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0ECBAB99-E393-45BA-83B5-5A129347274D@gmail.com> References: <9310F6C6-8B17-41D5-BF5D-E116910D646E@gmail.com> <83r0uekwlm.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Mickey Petersen , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Feb 24, 2023, at 11:55 PM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Fri, 24 Feb 2023 15:29:15 -0800 >> Cc: eliz@gnu.org, >> 60237@debbugs.gnu.org >>=20 >> Maybe it will help us understand the problem better, so here is the >> backtrace for the infinite loop. I=E2=80=99m not sure why = treesit_delete_parser >> would trigger gc, as it just calls two tree_sitter functions: >>=20 >> void >> treesit_delete_parser (struct Lisp_TS_Parser *lisp_parser) >> { >> ts_tree_delete (lisp_parser->tree); >> ts_parser_delete (lisp_parser->parser); >> } >=20 > According to the backtrace, it's the other way around: Emacs called > some function via funcall, and funcall decided it was a good time to > do a GC. Then GC called treesit_delete_parser, presumably because > that parser object was no longer in use? Ah, right. I forgot it=E2=80=99s not a callstack. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 21:37:40 2023 Received: (at 60237) by debbugs.gnu.org; 26 Feb 2023 02:37:40 +0000 Received: from localhost ([127.0.0.1]:42012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW6ux-0001n8-LV for submit@debbugs.gnu.org; Sat, 25 Feb 2023 21:37:39 -0500 Received: from sonic317-33.consmr.mail.ne1.yahoo.com ([66.163.184.44]:34408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW6uw-0001mu-BD for 60237@debbugs.gnu.org; Sat, 25 Feb 2023 21:37:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677379051; bh=OkpaUKVUzgs0P8+FfhO0RLM2HssPIKVBwjXtFoZucLY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=madwf5HWxrhxPOc50r4QZfbsaAOuDMgan+dH/O/HgoDLt2cMGxmK0xSXYCuNtOQtNRBnSybV8JORRvUyjbEswBzaVxnORopCAFL1dIHhKE/WIAWK0qZ3IwSqxrqlXqfXhN1Vm97itcDtVdcJMMmWqF+CFnhgcnBOj3a5ZjLoRLn6iuVl4l4OHIN3lMTUXPvcLVPxVwoHNB4ed2ZPCZD7vcGYHraK7B49jKS6GXTy9x2PBMx8np67+VxBtt+n0CGPiVCuWZbPLE6cRgZBd5ULd6CrLZ13AAyxwu/VpVehWdjmQ7+gCLUtS3REzGl4lc5TzHfJJ2l3jBousAAst5b2/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677379051; bh=vZCutoqRJyNCMcni8iEMchickMt9mXriBNKDqCRu9Tl=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=DXsnsGJ7RDswxRHRGTOJcIP3QbmNIEdJkXLGy2lAF8HVMluJQbDUKzcIIUiUYfwMfSC0FRMtS7QUr2OxKyj7Z7oFB0kw7fqCSnRYqepSfnfnU4BOLkSGmO7e4j/vcPB8JFnCCs9IrGicHm4hLhYq8WaW6l6DzJBDfPZydKEfeyBpn13TrMX6FECIgnnFehHYON/U22/AHg34Nt3aOsaW6wqcOkL8DrXTOrjaPEK53qEzRQS327GtYap8tPEfI7s1JSTGy+MJR1y0wqFOyA5s5CupDRXp+X0fB6UsjVWl/ah2Hyb8tTYDXyIsi81ozNuIEnxJLwp7JrMthcjDoH4j+Q== X-YMail-OSG: 61nXByoVM1k90c90MCfEKU2w3jOXPKDy_IPILFRo5eeJFRCzUnRSGsqAXolP1Wo PE3C.6DDsVeQGIgHPD27AW5qzNEXGeedv2.LdQwqKOzff8RlQ8XLaqxvfdQBVpCdOEqKQtdeGZcQ 43BjOATRKgy8bq6U8wGTa5uPD7o.f4RayI3r462tcCj8Xlw433t1pYqWg0jxmNk2phLiQji.ON_d EnT9_Y.ILftg1GbVodhAfBL_VWjFOuPKxOOrVUOKxjMYfxLeFItD1xxha4PhBVyBqlJhTFCb_1Nj EGiBWhSsAUgaO4SwLtzb_lSAy8lxjMxnZS9r1fA08cAd_3ai30f5Gk.VOrgx.6ycrhj.kaLFnSNr tuI5amsulGroEqHRQE.BvfTxzaF4ESdGsW8RfMrPwpMm.IMLuXP73YJx23F3MYtJORfUyJusJimd Jjv9QAO_860D4idfWApKzucN9D7GBNPXV97nF.LWoTEex1Lihy6VA.rYooXiXdoZlwtxRJuD4Ncv 0N4qorVZNa6dMV9Dt6TCAB7Hg.IMGoZSffTK7GoB0JqesqTHPZ8McGom95kWxT4NW._Fob2CqDpe QEv2S9CF.5uPw7Ox86nMvEsiGIMv14ewkeol5CjHcVuKCsOImTY9Pzgo_j.t5vvSXH9IhjqH3d1o 9PN6FP0MLYsE8gw1VRTsgdCCMg.acdBIUA.TBOxIJjbPNSRPLZ62hYQNSP0Jmrgr4YRpBolodDPi yul87y4Qs_3C4Q9E6RMD0vkp1csm9v.0XNND1L2Kz8qApV6GJ018KC24EfWVimpmc5UNoa3y5rU7 jD_QUj93P8xMlu4ZtH2OncXI9.rv9ZDSXwIIoAQT_l_SvrdGLtG0wm5i_9mdUX9Xtel.Oz4lOVPU W7qb_hE.DSjgngkqqKpLgyDMU8s0bB7cjA4_dnPb5Q5kp7B8W3R9Tz.QselF2sUfAGk12knc3Hd6 9Y4ozoTw3c8nRWpub.jNfcz6w_4.vbHqsghVysnKvO5rOn2DjahbdNawbQaMgE5SjER9xkUUEzGw k7KmIdxkZNgRDXX1V_qROgAk_sd.pKwAbhzA.0lT.0.ZB0VsW8C4eutE7AHTpgbDrno5cETfBtKV P7h5t6y05rBeuiU6h.3hDInBuwemdrihzsP30AsbuT7nCZjdyC3jj5DxR86MJcBQHixO3hkVHNpO mVY_ftZpS00Y9BxLGJ8HO0xaFhGlhc61zXFoDNE3Z97OoffEJGUw3lq2bP9pD9Xu2x41kmCPwqg5 hjPd8DjQZDuPjxvlpb6QpCgWvAt7jr1_maDAn7z.4cKtxCcqWVz2Xzg2vP0tzieiLibJhGpki4v_ IvBFlxM3QVJ_J9.pNAs4Kw9RbP.5KwEO6j8Zo7dLmRoJEIidLKtZ96pqzeZ4zbIMSjF0g57PaYGz N6YIdPTd8D89WpFJS58RqHRlesC9f4pFZy4bm37VpDfU_jPuywcxSc4KjVdAvPCGudcZ78XccYHd 3RCIEyacakiQ2hV0qt8ubUPdw3SE_aoJN1SGKIz3cTaAfX37nvausinDVQHq9nThlV4nZSnUGfJi s_HFpc1y4SGV5nQhiPkHz87V.bkNvKntD8E0KemjFVRVzM5wAygjtfCi7MgfPFUYhR0tawuW8cgV 6lPF_c6tce6q1m4frDfsI9.f0Pz3fCfaezf8OEyVZioAMNgScUfKe._cLUzVCFhGnu6dZZumzunm 7X9mcmQDUl.sWw5.QbYymKBsP5GEosrwaMjiHJUPiSc3y8pXAH3i1Qk8Tge1bAOXtFS7RYZxyNQq JZ7Sb5XY0rI71vK09l1sW7v5An2KBDrgNXRQ1kRop2l_BG67MolhEf2dDv_i47Td6lo3UfSTBj.T st_B8qnXQeeL6FG.SlTWLQwhnLCO5sHDXq9.18AQvYNOYLCtGUPR8nug6u2iXiPkvzcoqiPsgUeh rbOWksDMTPPTbBSgtXLgSdiZAufS_8wmB2FlNlO8w5mZDkA9r0.VYxmyFhWvnXi_F_SAFi1WfxJW ymKbV5vAgp0MhigSrVvXLACbaoMT8rf4nF_qGo6xfUGuGk3Luk2j3lp_Zng7u5j99FvJOul_1L00 u6d3hugU1haZy5dQ7uMM_fbX_MRRTJcRgRnhKhh.vTDws4pzw4W5ZyxV4BQIWYiJmU0A1pfhb8su zEJFPPcZwTZt9oArBuXPULLuwAeWKS1hqT_3hEibxTtnv4kLP2cR740Toiz6zuWqcA6dpyUUvxCX pzyDOeZheJyZk.ob9DjpXcXJFEDOIOwVPn28BmNWNkEOTYZltapQRQWvOW1EBu1fmohYCEBUYbwo K X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Sun, 26 Feb 2023 02:37:31 +0000 Received: by hermes--production-sg3-9fc5746c8-nc5k6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 688a0cf7fcef57037c3ece77a3cb88ea; Sun, 26 Feb 2023 02:37:24 +0000 (UTC) From: Po Lu To: Yuan Fu Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> (Yuan Fu's message of "Sat, 25 Feb 2023 18:01:07 -0800") References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> Date: Sun, 26 Feb 2023 10:37:17 +0800 Message-ID: <87zg9117aa.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.21221 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1049 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Eli Zaretskii , Mickey Petersen , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Yuan Fu 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 =3D=3D 0, free the > data and traverse the subtree and decrementing each children=E2=80=99s > refcount, and delete them if the count =3D=3D 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 01:14:04 2023 Received: (at 60237) by debbugs.gnu.org; 26 Feb 2023 06:14:04 +0000 Received: from localhost ([127.0.0.1]:42186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWAIO-0001RB-6o for submit@debbugs.gnu.org; Sun, 26 Feb 2023 01:14:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWAIM-0001Qa-IA for 60237@debbugs.gnu.org; Sun, 26 Feb 2023 01:14:03 -0500 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 1pWAIG-00012B-Vn; Sun, 26 Feb 2023 01:13:56 -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=GXMlQAhlTZm2i5DbCG7ITZqSuiJtKhxmg/e01hHT+uU=; b=f5NhsHgKhORWyEklhoRW JVi7AQhZRfEeb1fLjginTb+qOo9no4xO4KorRnFUdS9jVlzirPm/KAToh+m0a6SOJgAxak7dnq5Rj ebM4mwodWYdg12Wk8Zyo3ablMl5ARHTyGLdG7ePS6Q4CPqN6zE1UryQMlsIEGRWm71PpjNaA8MwPF zd6R7igVMlEF52UKhvXZS3+pweg/17klx1H7DUeQfohIN+cGpC5FpYLlhC7q5LJ0EZFb2wcgiFzDC lmh7bSFDDxvZ6mxpxcj13YrXmgkpT9MI5eBINnFN3BG1gRv0fz5svl+KANx/GsVgiekNNuHTrImxq lR0rXa0hP1xz2Q==; 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 1pWAIG-0006bX-Cd; Sun, 26 Feb 2023 01:13:56 -0500 Date: Sun, 26 Feb 2023 08:14:00 +0200 Message-Id: <83mt51j6mv.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu , Stefan Monnier In-Reply-To: <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> (message from Yuan Fu on Sat, 25 Feb 2023 18:01:07 -0800) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuan Fu > Date: Sat, 25 Feb 2023 18:01:07 -0800 > Cc: Mickey Petersen , > 60237@debbugs.gnu.org, > Po Lu > > > 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. > > 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. To traverse the tree, the function uses an array as a stack, which calls array_push to push new elements, which may call malloc. Stefan, could it be a problem for us if garbage-collecting an object calls xmalloc? Including if the "memory" profiler is running at the time of that GC? From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 01:18:28 2023 Received: (at 60237) by debbugs.gnu.org; 26 Feb 2023 06:18:28 +0000 Received: from localhost ([127.0.0.1]:42191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWAMd-0001YB-U4 for submit@debbugs.gnu.org; Sun, 26 Feb 2023 01:18:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWAMb-0001Xw-Qb for 60237@debbugs.gnu.org; Sun, 26 Feb 2023 01:18:26 -0500 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 1pWAMV-0001iF-FI; Sun, 26 Feb 2023 01:18:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=26sRbjoGGmhvc80+u1m2hZDnADgbeN+sEKUvO4ofFNY=; b=LyM5Iuua26cH wnuM2mg3g+OxJvTMKETc2kfxX7klkfwXPrVaQ8q1GTIZ/fTh1oldkyJpMvQEsjcfi8/ZKKKirI5Th xtoE94KMRR0cHXSW+0ncVKRUYOLir6jr1PfEYMrzq4IR/FTMocXwiFI6qmWB5SfRyNgBHVDkR/kVi /6c1o03zx7GFl9yNFmHB79W14FL99KzV8mW71qddihjimByioNfBaomJ49F5+NL08J3PtwneVxeGy L7D9KIF0UE5r2/EZLnKzptovRDrT9i+A9cFX/pxOx72MJCFyyfJsTY91DsVGJNzkNBEGFlZgHdaAi 4yuvoTEhSyxW1H2RC0fAxg==; 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 1pWAMU-00071O-Pc; Sun, 26 Feb 2023 01:18:19 -0500 Date: Sun, 26 Feb 2023 08:18:23 +0200 Message-Id: <83leklj6fk.fsf@gnu.org> From: Eli Zaretskii To: Po Lu , Stefan Monnier In-Reply-To: <87zg9117aa.fsf@yahoo.com> (message from Po Lu on Sun, 26 Feb 2023 10:37:17 +0800) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <87zg9117aa.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Eli Zaretskii , Mickey Petersen > , 60237@debbugs.gnu.org > Date: Sun, 26 Feb 2023 10:37:17 +0800 > > 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. That's what the "memory" profiler does, AFAIU. It uses xmalloc as a poor-man's timer. It is rather useless and misleading, but if we remove it, platforms that don't have timers and SIGPROF will not be able to profile. But maybe there are no such platforms? (DJGPP has setitimer and SIGPROF, so the MSDOS build shouldn't be a problem, although I never tried profiling in the MSDOS build.) From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 04:42:23 2023 Received: (at 60237) by debbugs.gnu.org; 26 Feb 2023 09:42:23 +0000 Received: from localhost ([127.0.0.1]:42354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWDXz-0007GT-3v for submit@debbugs.gnu.org; Sun, 26 Feb 2023 04:42:23 -0500 Received: from mail-lo2gbr01on2115.outbound.protection.outlook.com ([40.107.10.115]:32282 helo=GBR01-LO2-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWDXx-0007GB-3L for 60237@debbugs.gnu.org; Sun, 26 Feb 2023 04:42:21 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Itm0aY+wxQ/LkpWQqaRDvOr95LOibnV63BnLqZ8uvscdsnH3IbHxt+ivRGUv52CeBF+iF5bxC2x9hSLpM4jkG80+j1bQgGmGcdxbo6RfiP6WYwyukG1xY93V8K2lxuKCdOllLRocCYG6x0s/WNKJS4gsJZSe2UQGahLGqObirThwCfRw5GWv3g7Yb8P7nJfbxAKFRL4yHFhRzC1z50XT1oaaZVx/yMvovHXGee/gdAzfNRksb6pMZTtAUGl9eHH7yX2DOwpbeybJUO7dVh/GIo5xjwhdkpbsLxYhozJK/vxBG6wJ46Fsgrq9tGDw69dnDB0OsXKOtZkCy+oBU8iVBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=o306s32r8AFhr1XVpHtG7tp/bTlZQrrtqcbsy0xVHBI=; b=FQjhv8n2nrSBNkh+qAgGBHMkswN08aJ/u4l2gu+8pL2zYthamZrqR0e3CBLj45tX8KTDNKdR7WXbDKMBgmBR6AAAxEu6PhykitWqvHkNNBOMDd23Xff23XWcpH82wVcAMEg2lw3i11xsRxvQev2q7uvlwYnTohAByHAfl0/ZD9zb9S++92l2ewmT7p6kbAlYj7V6yc4pAtNwKZAJm6wDq7UFplgJ5RbTebMBvbIF9I8iitZBT+SL8h/INNuyRKXT0LPU6iWutMVAsMRrVPt2KDJrsACDxmfcoEvvZAbiXnBgWXg8jChtZJX9PTEPW4X7nmNANAYBuolcBE1ESXLnBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 178.79.136.144) smtp.rcpttodomain=debbugs.gnu.org smtp.mailfrom=masteringemacs.org; dmarc=pass (p=none sp=none pct=100) action=none header.from=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semantical.onmicrosoft.com; s=selector1-semantical-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o306s32r8AFhr1XVpHtG7tp/bTlZQrrtqcbsy0xVHBI=; b=XRJoNW4Uicnl7F32t58cMNgSpsqtsJ/spPq1jIks96qbshC3RSEQMIuDEY4zSQncP5mtCOHtcsfby/aQNISFuq7OmfMfeEwywDAvX65TxbPQD/Rwb8jrSa98k4zTwi+gExsMnser0taiy1YX+dcQue6ThD2GcShqyGuYNi6SpCs= Received: from LO4P123CA0332.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18c::13) by CWLP265MB6705.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:1ec::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.26; Sun, 26 Feb 2023 09:42:14 +0000 Received: from LO2GBR01FT032.eop-gbr01.prod.protection.outlook.com (2603:10a6:600:18c:cafe::55) by LO4P123CA0332.outlook.office365.com (2603:10a6:600:18c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.27 via Frontend Transport; Sun, 26 Feb 2023 09:42:14 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 178.79.136.144) smtp.mailfrom=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org;dmarc=pass action=none header.from=masteringemacs.org; Received-SPF: Pass (protection.outlook.com: domain of masteringemacs.org designates 178.79.136.144 as permitted sender) receiver=protection.outlook.com; client-ip=178.79.136.144; helo=semantical.co.uk; pr=C Received: from semantical.co.uk (178.79.136.144) by LO2GBR01FT032.mail.protection.outlook.com (10.152.42.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.12 via Frontend Transport; Sun, 26 Feb 2023 09:42:13 +0000 Received: by semantical.co.uk (Postfix, from userid 5001) id 30744114002; Sun, 26 Feb 2023 09:42:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=masteringemacs.org; s=masteringemacs.org; t=1677404533; bh=BKSghC041d8/brkYSUVehB2EoaX6ZuLM0FASe1L3kl8=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=JE0t0UsM/D6x+Co/RCLG2TyycFmSs8Qqz4Bcwt/gJtjs+rid/6YKP7V4l73t76ub3 whNnvr55/44cgKOL8MqWuHR5eQ0TcLf1zOfDAspKKtMX4IdshhzTkQcZ45e4lBoINv AbMKe+Ka6VZ43hqjQ6Y0OplY+k6mwksxarZ1FB2A= X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on semantical.co.uk X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS autolearn=ham autolearn_force=no version=3.4.2 References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> User-agent: mu4e @VERSION@; emacs 30.0.50 From: Mickey Petersen To: Yuan Fu Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Date: Sun, 26 Feb 2023 09:41:18 +0000 Organization: Mastering Emacs In-reply-to: <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> Message-ID: <87a610wyod.fsf@masteringemacs.org> Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LO2GBR01FT032:EE_|CWLP265MB6705:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: d9d0e844-a857-4d84-77d4-08db17ddbd95 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0M3TY9JIcRNM1fR/3ZKA0sgUjgjnoP9wa62LYfeK8PuPNH08xhApU3MhG3khm1U4roWinP4R9Hae0xL++YTfgAYaFDedFugFTxbtJTBiRM66V35lLXZs4dZI4gmCg5Z11C4XrYAVlZzf5Ff4dO+P8OEnh1Um/9pMxApooa1FrIkslhVmssTpGCV4fVYtQKCwslGhtM9zKQAoLmJGk8WfwHo8/bdk3BU+O5j5DusIXa11+nvMAoynmFjrAwe7Wmhao4DIPjo4XZd30brNXnnN6cSmHLoTmXFjyDw/Wb0vwdexcOv0SXSCw7G/1nfJS22h9O+SIQgsVizfQ/FeoJKzNQBLp6kNtmJQn75UpuBc5lFDSSPmX4pNwPRhGT6l+f5mz5j1hsqjF143bMGWZK9qA56VrwIyfWAU4BtYenGp7fO+qwSBk9x0Xi4aMzhSNTmIhMXSRPAZkIX0VqeGAkau8hdGUJrliA3YZ6pknH5aF4DFb8FNGrb4im7GxjgXgNdPzIlqPNOOWXJm9IzsmkYpP92XB1bC2n4Gunvlh3ywJS5tqOhqv//Ub7EEfC+MBl3t+zaFivqlRIx5LvUv/N300uMyVKExIki+lTgj6zA792oguBqK9QbetIccSr+SqXMiRPTHlf2KGQMVHCP1DYCvIm3+1+lZ/gFdsv7Y0lLc6idOsqP93g1p0kpxpL/26MDfMx/tvuGWr8jWv8Qy3SbLe4ysguxY9Amd1cwnkiKMMk0Amg7fgEbVMjKgwIB+SxXV X-Forefront-Antispam-Report: CIP:178.79.136.144; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:semantical.co.uk; PTR:semantical.co.uk; CAT:NONE; SFS:(13230025)(136003)(376002)(396003)(39830400003)(346002)(451199018)(46966006)(36840700001)(6266002)(186003)(7596003)(7636003)(83380400001)(356005)(6862004)(8936002)(8676002)(70586007)(4326008)(41300700001)(70206006)(2906002)(5660300002)(36860700001)(336012)(36916002)(40480700001)(478600001)(47076005)(26005)(107886003)(2616005)(42186006)(316002)(36756003)(82310400005)(54906003)(86362001)(38230200001)(14776008)(79816003); DIR:OUT; SFP:1102; X-OriginatorOrg: masteringemacs.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2023 09:42:13.8563 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d9d0e844-a857-4d84-77d4-08db17ddbd95 X-MS-Exchange-CrossTenant-Id: a4e27e3d-bab0-45e8-8942-e64cf9fbd34f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a4e27e3d-bab0-45e8-8942-e64cf9fbd34f; Ip=[178.79.136.144]; Helo=[semantical.co.uk] X-MS-Exchange-CrossTenant-AuthSource: LO2GBR01FT032.eop-gbr01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP265MB6705 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Po Lu , Eli Zaretskii , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Yuan Fu 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 10:16:45 2023 Received: (at 60237) by debbugs.gnu.org; 26 Feb 2023 15:16:46 +0000 Received: from localhost ([127.0.0.1]:44823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWIlZ-0002ru-KO for submit@debbugs.gnu.org; Sun, 26 Feb 2023 10:16:45 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWIlW-0002re-1v for 60237@debbugs.gnu.org; Sun, 26 Feb 2023 10:16:44 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 99722440BCB; Sun, 26 Feb 2023 10:16:36 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 44D4E440BB4; Sun, 26 Feb 2023 10:16:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677424595; bh=bNHOBM/JYOldGWbwIQeau3eBSayJjMa4PGxHBNiG9m4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OE0u7366LykQJZXS849qQ3Wse63yEPPooIlE8A99ZMyjuX/g9cFrYUlFCTRnfRSWG TETzlaEm0BoEZrzNIkK2fsQ0ZmN/FOrsOeGQ2Wre07Pjr6xbuw9BghwO9nlM9QusRO oBsIyT8ICU1dm+mHH68wWQqi+q0sIW6pMq1+3MV5j5uaMJobNbp/aXOghDzc2AIRcs xWQ6fGspv/pGlKuAmJ/HZdhuMA9jpaQqgYBvGnFphn8bYey7DlfG5d5bBeQ8qeK5Ue 5RzV0hP6tjG0hVniv2TOqhtzxE6AHLwtkNeDltuQeOUR8i2KX3uQHJaqzgFWKSWHCW USx4bfMZv0nWw== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 03DE51231DD; Sun, 26 Feb 2023 10:16:34 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <83mt51j6mv.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 26 Feb 2023 08:14:00 +0200") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sun, 26 Feb 2023 10:16:25 -0500 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.154 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, Yuan Fu , mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Stefan, could it be a problem for us if garbage-collecting an object > calls xmalloc? Including if the "memory" profiler is running at the > time of that GC? I can't think of a fundamental reason why this would be a problem, but as you've seen some code may not be quite ready for it. I suspect the simplest solution is to do something like what we do for the cpu-profiler, i.e. handle the "time within GC" specially by checking (EQ (backtrace_top_function (), QAutomatic_GC)) to determine that we're within the GC. We could just not count those xmalloc calls, tho better would be to use generalize `cpu_gc_count` so it's also used for the mem profiler. Stefan PS: While the mem profiler was originally thought as a poor-man option in the absence of timers, I've occasionally found it handy to track down problems where we're spending too much time in the GC. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 19:35:12 2023 Received: (at 60237) by debbugs.gnu.org; 27 Feb 2023 00:35:12 +0000 Received: from localhost ([127.0.0.1]:45343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWRTz-00064b-NR for submit@debbugs.gnu.org; Sun, 26 Feb 2023 19:35:11 -0500 Received: from mail-pj1-f47.google.com ([209.85.216.47]:52903) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWRTx-00064J-6D for 60237@debbugs.gnu.org; Sun, 26 Feb 2023 19:35:09 -0500 Received: by mail-pj1-f47.google.com with SMTP id l1so4418514pjt.2 for <60237@debbugs.gnu.org>; Sun, 26 Feb 2023 16:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YNZ7NiU2j3LzbZF+wRyPLEfIaxQh8hTpW1dZJI29V/o=; b=RCFxjkoyNMwR3GP3sXgFsZJhYUp8s6RnDkXWKY7JGic7yUFSltyGcEvPLm1fs2wZLa XswfZsX1srfqAN5yQyRKlJYI1PBSGvoFOyzguDe1gm/ajG3MBRPHOld+Bd4ONrAx1apm /p8ye8z9J8HIOha+pWaM+NhGYSy0KAttSUvH29ka3JewPo8ihdUIlFEGGq+L/CBptm8R GzvxJ/tk/2sz47a0helblK+uDKbOUbmrRJpqXuRCWBf/9BLicJxpHRl5NtGfYZxybJTr YAtIy/dbyhUWcqW7GCVyVaOmezeSyuIeJoxV1PpYPanAGkCUv+QoZIZi/lnL0dT8xBq/ kjMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YNZ7NiU2j3LzbZF+wRyPLEfIaxQh8hTpW1dZJI29V/o=; b=tgv/HuJ+jyfcR2Xyo4JZBmseCfX3hkAyR/kRkmzVKA4gsVgncXKiyZGRNCSu8pszPq 3dGbLVFUkDY702Zazb3MLyHYaCg7FqOdZVkcBkwFUIlM59cRx7Pt16Nu7AUa1dKIlxL9 Lt8WAb0MwPPEMGVpFA0eEOwT9FhusTLy8W5z8kHXFdOsezkIBP11p3NWLKVzaTsvfOKZ iytvv0ijeXRFgYuUf4sgc390lQR0Vh+Mt0H9Dmv6cygobgWUl+Ci6g2FyVhwZNR9mpWs 0jUdEBV1Wdv+nv3MLfxGmtPpw6QTFS6NKPHRqSpKBFdv64s8nfmXx+NJo4YEOGhuexJ0 CL+g== X-Gm-Message-State: AO0yUKVUOXtkgkShYBy1exY/a/zjyoFDb+P9HrMPvM9kDx6ydegHiraK zAqfGU5Jj4bcPW+2Wb3TV2k= X-Google-Smtp-Source: AK7set97y17dsaAavvCpLREKSZkMksMxErNPdQQmUVAbd5DmomrOBXuqMfvanh+C67BWO0vSRYU3BA== X-Received: by 2002:a17:90a:e7ca:b0:233:eb8c:d7e9 with SMTP id kb10-20020a17090ae7ca00b00233eb8cd7e9mr26260856pjb.41.1677458102736; Sun, 26 Feb 2023 16:35:02 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id t12-20020a17090ae50c00b002376d85844dsm3019402pjy.51.2023.02.26.16.35.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2023 16:35:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node From: Yuan Fu In-Reply-To: <87a610wyod.fsf@masteringemacs.org> Date: Sun, 26 Feb 2023 16:34:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <87a610wyod.fsf@masteringemacs.org> To: Mickey Petersen X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Po Lu , Eli Zaretskii , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Feb 26, 2023, at 1:41 AM, Mickey Petersen = wrote: >=20 >=20 > Yuan Fu writes: >=20 >>> 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. >>>=20 >>=20 >>> 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? >>=20 >> 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. >=20 > 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=E2=80=99s product, = tree-sitter itself doesn=E2=80=99t 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= From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 27 03:26:53 2023 Received: (at 60237) by debbugs.gnu.org; 27 Feb 2023 08:26:53 +0000 Received: from localhost ([127.0.0.1]:45820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWYqT-00046t-4x for submit@debbugs.gnu.org; Mon, 27 Feb 2023 03:26:53 -0500 Received: from mail-cwlgbr01on2126.outbound.protection.outlook.com ([40.107.11.126]:28241 helo=GBR01-CWL-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWYqN-00046b-Vg for 60237@debbugs.gnu.org; Mon, 27 Feb 2023 03:26:51 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=frVghmeB5aWH4i4j30YPueo/cpmoT7NPb+VhdOhcoJYtwMNU8aglx29FGouqwqSPOSupQ/JCIWkR754cdfOxrAv4s2cg3HccxAO2s1SdUrX3g3BdUZSvsPhW2gfaTArvifRzSgTKb3WzT/rulgPYkdrTHqBXXebsFfB7bNv934pqMnzm4X04gFHiSq3LjllycztIKIEbxPpdMS2yGfPIgbu+zub2VbPUwyrMEX0uO27q8eOOLZZhPEBZdM84bl7aX4CSj/vqYgdjixdYJ3pVI1qbz21N3Hm/JEjtLPtrGLlu3qNSCqgx2hpcAQ2ld+Uy6ZR1kwNn8+4lT8d1GH1inw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fTpMs1SeDyEFWXqdKAMOvcpKlK+f61wjdXHKXgu6+Y8=; b=GUWa1n1DePA1q8nN/OgK+oht8T1Ep4oJSDAF/SrI2hL1j+kM5+pjZ6+h/LMhrjzRY3SFfpolkcYqV2SjHMszjmUd8MfqG7PB6oKBBf5bxY02em3y+ZNO4sH0F9FWWaISohanStdmVWaxo7mLAZr5pIOrHZb3neR4GYyhxeFx3FnJdN5NSC7cImK3/R77sHTNZN5fCHm2JlVxcrObYZD8fPV1a98Ql4WBG0Zrq42L71TsWqWSUlFwPTJnsN/b7VMcwmMeOqNzmYDoqei1PC+/P+WqE2sXlImo4Ck+8rWkQpSd7yW5GOlqWOYvtfKTOdC3bcZAUUWU8ImqUNw5F4Qz6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 178.79.136.144) smtp.rcpttodomain=debbugs.gnu.org smtp.mailfrom=masteringemacs.org; dmarc=pass (p=none sp=none pct=100) action=none header.from=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semantical.onmicrosoft.com; s=selector1-semantical-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fTpMs1SeDyEFWXqdKAMOvcpKlK+f61wjdXHKXgu6+Y8=; b=e6eiHRGXxdxw+Sz+I3ImScX7vOSjtmkyFu+odMfjcYTr3+N2WGec7egQ4q34G3wlBxZrRGH1tCF6GBo9Eo5Gj3LiqmAKygMaRhl7XKYJ7DCOJapeLsoaCM0m1P29MugeiPBAhCboHvHk4itM48ov+7q3VNZT6HeIdg5ftceNqRo= Received: from LO3P123CA0029.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:388::19) by LO0P265MB5166.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:282::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.29; Mon, 27 Feb 2023 08:26:41 +0000 Received: from CWLGBR01FT021.eop-gbr01.prod.protection.outlook.com (2603:10a6:600:388::4) by LO3P123CA0029.outlook.office365.com (2603:10a6:600:388::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.29 via Frontend Transport; Mon, 27 Feb 2023 08:26:41 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 178.79.136.144) smtp.mailfrom=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org;dmarc=pass action=none header.from=masteringemacs.org; Received-SPF: Pass (protection.outlook.com: domain of masteringemacs.org designates 178.79.136.144 as permitted sender) receiver=protection.outlook.com; client-ip=178.79.136.144; helo=semantical.co.uk; pr=C Received: from semantical.co.uk (178.79.136.144) by CWLGBR01FT021.mail.protection.outlook.com (10.152.40.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.12 via Frontend Transport; Mon, 27 Feb 2023 08:26:39 +0000 Received: by semantical.co.uk (Postfix, from userid 5001) id 34080114002; Mon, 27 Feb 2023 08:26:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=masteringemacs.org; s=masteringemacs.org; t=1677486399; bh=AozE48fjbkx6bd3Dz/v8NGvAr5uf4oVBGaGjEr1988U=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=fSUNF0qPHG6QPIolSCOzYQWu8vqjfJjj5uUVGcLqNUOngf6nIFGmL8BzjO1HRgZbF OKes38JP38Vvk+lzNWp+eNBTDgtpH3y/hP5YsCxMiCdaEAxSwIMiw0rmkbVDtbrfA9 /BhnxVMWyL7uXFYHH9oBFh58eIlRg0o2v4yE+uj4= X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on semantical.co.uk X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <87a610wyod.fsf@masteringemacs.org> User-agent: mu4e @VERSION@; emacs 30.0.50 From: Mickey Petersen To: Yuan Fu Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Date: Mon, 27 Feb 2023 08:22:04 +0000 Organization: Mastering Emacs In-reply-to: Message-ID: <875ybnwm2r.fsf@masteringemacs.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CWLGBR01FT021:EE_|LO0P265MB5166:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 20be34b6-2ab0-4827-7859-08db189c594f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +Rn4LjjOteXlcFo8GhJZJFqhJ/v1JnvPv++XgdpdG5EESrYivLYLG+i5bvWMzBO45UaUBgWlzodOtvlTYxIAQ3K182HsmiSzz2cLnwAOr3BL+80ujZl+eVMMDOgrxBtUXcd8IZizi5PvIxtZXVtcP8eTsZHTV1iSmTPKdPyLGeTKigPMpt9BWe93IMnLeRK+LSBKUkYRf9fHGLk3Tu0kxs32mFhas1AZ7/mIUApK7wyBMw14Tr7oaZ6L9qIim7d1pT5+OkVsQA9XiOsV/D2LZOcyAKEKV5TUTqzQbf5lk5kFjfWztM3qIdJxlNMw2ejhFYF459ol4LBhj0zDpoSCukR/+1g0VGUKg3d00bWalsmjFrFqP5U8qrpCJ9z3X/Hcz9E2D68q8iTV5Mt773l8vjI5OiqUdH5bZy0OKM/ZEJ64AvVOuPsLuRZc34sccZafxhITNN3nhY/r3a/G59C61f24Eq1eWW0tPAkYT+dlb9R0hiWmvebHMHEdUnJdgQRKTH2IFHFAtGVoJ40l868RHUO4FEbq5cfBIgs2ejh4s+MO1HAnOx0ShTtzJelukThBrtMOVWlxWPmw3Epo4IZZyzf2IVMHeC+kOE3Ec9uB0tdjQDbMxUOg6dINDe9EWeF3DoG6Z8ruygRevBt96hcKkAJELj1I2f1wVoTM9gMQJZYu1nTh0M9L7kbCYIJ5xqpULVnWpomSeZq0XAhgxunKX8bswcMXbswk8ZBjDS2SYOY5dtQt4R5AUldsjHPm5IUq X-Forefront-Antispam-Report: CIP:178.79.136.144; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:semantical.co.uk; PTR:semantical.co.uk; CAT:NONE; SFS:(13230025)(39830400003)(396003)(376002)(346002)(136003)(451199018)(36840700001)(46966006)(41300700001)(83380400001)(70586007)(70206006)(4326008)(8676002)(7636003)(36860700001)(7596003)(36756003)(2906002)(82310400005)(86362001)(40480700001)(356005)(6862004)(5660300002)(8936002)(47076005)(2616005)(336012)(36916002)(478600001)(107886003)(42186006)(6266002)(54906003)(316002)(6666004)(186003)(53546011)(26005)(38230200001)(14776008)(79816003); DIR:OUT; SFP:1102; X-OriginatorOrg: masteringemacs.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2023 08:26:39.4933 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 20be34b6-2ab0-4827-7859-08db189c594f X-MS-Exchange-CrossTenant-Id: a4e27e3d-bab0-45e8-8942-e64cf9fbd34f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a4e27e3d-bab0-45e8-8942-e64cf9fbd34f; Ip=[178.79.136.144]; Helo=[semantical.co.uk] X-MS-Exchange-CrossTenant-AuthSource: CWLGBR01FT021.eop-gbr01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO0P265MB5166 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Po Lu , Eli Zaretskii , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Yuan Fu writes: >> On Feb 26, 2023, at 1:41 AM, Mickey Petersen = wrote: >> >> >> Yuan Fu 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=E2=80=99s product, tree-sitter > itself doesn=E2=80=99t 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. OK, so let me explain: Touching the buffer for any reason invalidates the whole tree; that's not good. It's not good, because a lot of the information may still be useful and viable. Outdating the node is not a bad idea as it avoids a lot of 'traps' around accidental modifications that can corrupt things without the developer's knowledge. I'd like to be able to access all the information possible; perhaps behind a flag variable like `treesit-allow-outdated-node-access'. What I'm really mostly interested in is: - How well the node references handle changes in byte positions in TS. - Does changing something at X shift (like a `point-marker`) everything below it? Does an outdated node correctly reference its new location and state, such as changes to children or its position in the tree? Right now, Combobulate can make a proxy node, which essentially captures the basics of a live node and stores it in a defstruct. That way I can at least retain the start/end, type, text, etc. of a node and still do light refactoring without contorting myself to do things in a particular order, which is not always possible (like delaying editing to the very end.) From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 27 04:06:14 2023 Received: (at 60237) by debbugs.gnu.org; 27 Feb 2023 09:06:14 +0000 Received: from localhost ([127.0.0.1]:45880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWZSX-0005Co-H0 for submit@debbugs.gnu.org; Mon, 27 Feb 2023 04:06:13 -0500 Received: from mail-pj1-f47.google.com ([209.85.216.47]:33588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWZST-0005Ca-8f for 60237@debbugs.gnu.org; Mon, 27 Feb 2023 04:06:12 -0500 Received: by mail-pj1-f47.google.com with SMTP id m3-20020a17090ade0300b00229eec90a7fso11309503pjv.0 for <60237@debbugs.gnu.org>; Mon, 27 Feb 2023 01:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nZu6xFSQkxvqLKm/e2LmeWg0DVeD9R8hEciRBmakKAQ=; b=I7mICWON9FEi7M66o/2jkpavmIYykZD7vL1BJ2lWMZDfSV146Jj+cVp2CP3u0bdxi9 t6wrDd32Qqes6X8txmIEMhoUb4cl4iE7Ppapdjptz/nAPRqwuD6hYJQCST+iS8Wn61/c csPqgUt1DghRz8jmqeyeguSNMRJVnBvtHiOupoyF/gDGbTsrn5hYP1AX8pKh15VEX722 J6TA20/gfp5syKJgE9hYD9flrGOxgvVAKh6Xd76bQY0Qt6dDCeSFAglmF0y2f+95YiCX D9drVpsFXEuacY9zGpvszhaueJXPgSGD0ZYB7eBd0mq4KZHIbFYu4GgtTwe9zJcKAsEU yyuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nZu6xFSQkxvqLKm/e2LmeWg0DVeD9R8hEciRBmakKAQ=; b=Uhc9VvvD6QdDneuMpwgsI7yhU/7kHncD9JQupREquixo5fLuG0EADo+MNilGWbNJ+y Ngip0t374h+KJWlYgjIdbGGY4+JKFGAInoTZ83RljRMGCsyr71BTNNlQ1pXWDRFB6oY3 vYnMDyL+x3y+NT2v/hdAu5rjqt6XmhQiQJztAhyEzT7nEHnb3fRtKIOqNnQlNnFF6vb7 h52QRfZUCAkZMxcVbWYBIYfzMurIj2Ez9r1Rma4eS0TI904CaRrYKF2iuEPa8n6bAu1G SkbXvUSJ703HPvkIqtqF8NUgzST8Nk5U255aNxdSLGL4TMJg8rORN34A+4vmy38Ct1TT N7rQ== X-Gm-Message-State: AO0yUKUA886oEMpJk15bO99p13EXSZGLuPQVAO7DMJdpAf/9zxVdBg4m gnpoBDDJqd3afc5h/fFY0Zk= X-Google-Smtp-Source: AK7set/KZPnxFj8amL5C5SfoD7YXaDq5p048AuZ01pqQf5+iTanl14VH1N141ynD/+oBXa58p87ReA== X-Received: by 2002:a05:6a20:431b:b0:cc:9f59:4562 with SMTP id h27-20020a056a20431b00b000cc9f594562mr10535641pzk.53.1677488762875; Mon, 27 Feb 2023 01:06:02 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id l3-20020a62be03000000b005a852450b14sm3751189pff.183.2023.02.27.01.06.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2023 01:06:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node From: Yuan Fu In-Reply-To: <875ybnwm2r.fsf@masteringemacs.org> Date: Mon, 27 Feb 2023 01:05:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8A0520AE-7C8C-43D2-BE93-E80D5CC8856C@gmail.com> References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <87a610wyod.fsf@masteringemacs.org> <875ybnwm2r.fsf@masteringemacs.org> To: Mickey Petersen X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Po Lu , Eli Zaretskii , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Feb 27, 2023, at 12:22 AM, Mickey Petersen = wrote: >=20 >=20 > Yuan Fu writes: >=20 >>> On Feb 26, 2023, at 1:41 AM, Mickey Petersen = wrote: >>>=20 >>>=20 >>> Yuan Fu writes: >>>=20 >>>>> 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. >>>>>=20 >>>>=20 >>>>> 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? >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> What kind of exact interface (function) do you want? The >> treesit-node-outdated error is solely Emacs=E2=80=99s product, = tree-sitter >> itself doesn=E2=80=99t 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. >=20 > OK, so let me explain: >=20 > Touching the buffer for any reason invalidates the whole tree; that's > not good. It's not good, because a lot of the information may still be > useful and viable. Outdating the node is not a bad idea as it avoids a > lot of 'traps' around accidental modifications that can corrupt things > without the developer's knowledge. >=20 > I'd like to be able to access all the information possible; perhaps > behind a flag variable like `treesit-allow-outdated-node-access'. What > I'm really mostly interested in is: >=20 > - How well the node references handle changes in byte positions in TS. They don=E2=80=99t handle position changes. If the buffer content = changed, we need to reparse. Once we reparsed the buffer, a new tree is = born. While it is true that the new tree shares some node with the old = tree, tree-sitter does not expose any function or information that tells = you which node in the new tree is =E2=80=9Cthe same=E2=80=9D as which = node in the old tree; nor does it tell you whether a node in the old = tree still =E2=80=9Cexists=E2=80=9D in the new tree. Now, there does exist a function (in tree-sitter=E2=80=99s API) that = allows you to =E2=80=9Cedit=E2=80=9D a node with position changes. But = a) I=E2=80=99m not sure how does it handle the case where the node is = deleted by the change and b) it is not very useful because once you = reparse the buffer, the new tree is completely independent from the old = tree (ignoring the implementation detail which is not exposed). >=20 > - Does changing something at X shift (like a `point-marker`) = everything > below it? Does an outdated node correctly reference its new location > and state, such as changes to children or its position in the tree? Like I said above, any buffer change will create a new tree with no = relation to the old tree, so there is no shifting. And there really isn=E2=80=99t a =E2=80=9Cnew location=E2=80=9D: we = don=E2=80=99t know if the old node is still in the new tree. Mind you, = even if the node is completely outside of the changed region, it can = still disappear from the new tree because of change of its surrounding = context. For example, in the following C code: /* int c =3D 1; If I insert a closing comment delimiter, and buffer becomes /* int c =3D 1; */ Even though int c =3D 1; is not in the changed range, nor did it=E2=80=99s= position move, all those nodes (int, c, =3D, etc) are not in the new = tree anymore, because the whole thing becomes a comment. I made any access to outdated nodes error because there really isn=E2=80=99= t any good reason to use them, at least I didn=E2=80=99t think of any at = the time. And make them error out should help people catch errors. >=20 > Right now, Combobulate can make a proxy node, which essentially > captures the basics of a live node and stores it in a defstruct. That > way I can at least retain the start/end, type, text, etc. of a node > and still do light refactoring without contorting myself to do things > in a particular order, which is not always possible (like delaying > editing to the very end.) IIUC, you want to do some very minor whitespace edit to the buffer which = doesn=E2=80=99t really change the parse tree, so you don=E2=80=99t want = the nodes to be invalidated for no good reason? Not erroring on outdated = nodes is easy. As you said, we can add a treesit-inhibit-error-outdated = variable. But not it=E2=80=99s not so easy to automatically update = outdated nodes=E2=80=99 positions (with aforementioned tree-sitter = function). However, if you are making those changes, you much know how = to adjust your nodes position, right? So maybe it isn=E2=80=99t a = must-have for your purpose. Yuan From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 27 09:32:22 2023 Received: (at 60237) by debbugs.gnu.org; 27 Feb 2023 14:32:22 +0000 Received: from localhost ([127.0.0.1]:46478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWeYA-0004lw-5r for submit@debbugs.gnu.org; Mon, 27 Feb 2023 09:32:22 -0500 Received: from mail-cwlgbr01on2092.outbound.protection.outlook.com ([40.107.11.92]:60321 helo=GBR01-CWL-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWeY6-0004lh-NS for 60237@debbugs.gnu.org; Mon, 27 Feb 2023 09:32:21 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KvSELHWa5dFpf9bc42aXSSPJCE4EoxgIU0II16JadcTNcUAmbJldnyDbpKmdxhGvyuxUqk0KLpHONB4PVBxf9521YxyxFkYmEMClPxN3W5gmfDvEhgDigBveJaActMR/8AgJCm5Z406qh7gvXqc1+TuTazP/XpaA80wRjXuOdeZlT97pexOpxkdeePraHLX012UvXUkETqWji7zzioIJFYqXIkP9ytXa1S6rA9M1TadJHYo1Z8pZ3pUwty8KwgUGT7aceMM57EgBDgsFEsxBXRlGhTuDv+ORGv1dAt9CrNIJwsHGXPO5tqaT6VxT88HBln3fP/YumweBRBVLgcn9mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8VzTqGTi4hCv9E5zy18CQXKefZ16G7E8BFXJj36xunA=; b=jU1I9sExMiwKsR09EWUjmW1Jaih5qZHx1X2fCaASqKDIcxL6RIpCvM2NQK2URRw5eNJ1B4L7z1at2iWe+aNl2Tuk4ZXsEIvgl30ZbOr/GEVprZ3WPDRcVXB5iqzrWZm26DM4OdHdMJjZeGff/cArGUPda3qC23OZ1wUXV9pS0F8ExATbPSJhy1oKaVwwACvXhbZ8xnXVVPqNKi0NdnBmoaw4yacMTqnk7jdnfff/19WsGXIRQQbhwC3qsh+fUyNbMdkzXBV7wOabdzt/yd6VW61EwUYx6QYzVp/i0dj0jTC0q90sIp+C/H/PO5YDzIGC7FZB8H05XJ/fx1ZnRY2OoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 178.79.136.144) smtp.rcpttodomain=debbugs.gnu.org smtp.mailfrom=masteringemacs.org; dmarc=pass (p=none sp=none pct=100) action=none header.from=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semantical.onmicrosoft.com; s=selector1-semantical-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8VzTqGTi4hCv9E5zy18CQXKefZ16G7E8BFXJj36xunA=; b=sRECdiw256l275uqs0Oyzel0OeFpENihJE+vqave5HHuLIbAws8KhE0HltrMf9+m7OPHaqCP8X0vp/n8cSN0miaNJBRhYBOQDGvB+7OAXehVMRwIiZV0Rz9Pl4tZbrBUAjjT3xhxb+ukCyfglEqkO/8aQe1SgPkIg2+rRSmjHQw= Received: from LO0P265CA0001.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:355::9) by CWXP265MB2184.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:79::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.29; Mon, 27 Feb 2023 14:32:09 +0000 Received: from LO2GBR01FT034.eop-gbr01.prod.protection.outlook.com (2603:10a6:600:355:cafe::c0) by LO0P265CA0001.outlook.office365.com (2603:10a6:600:355::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.28 via Frontend Transport; Mon, 27 Feb 2023 14:32:09 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 178.79.136.144) smtp.mailfrom=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org;dmarc=pass action=none header.from=masteringemacs.org; Received-SPF: Pass (protection.outlook.com: domain of masteringemacs.org designates 178.79.136.144 as permitted sender) receiver=protection.outlook.com; client-ip=178.79.136.144; helo=semantical.co.uk; pr=C Received: from semantical.co.uk (178.79.136.144) by LO2GBR01FT034.mail.protection.outlook.com (10.152.42.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.16 via Frontend Transport; Mon, 27 Feb 2023 14:32:08 +0000 Received: by semantical.co.uk (Postfix, from userid 5001) id 42A65114002; Mon, 27 Feb 2023 14:32:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=masteringemacs.org; s=masteringemacs.org; t=1677508328; bh=ac10OEOkOj9n8GYLWyDYVXHJyQe8Iw2WxvN+cSuWEXQ=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=KViaJVpFbF4uy4ZSqKoTdWiKz4nSCjVuNE/gWkGVncFkbyILasltyUiepnrOt4c/Z IoHqOpErEf7Ef5O6FGu2ZtTCy1kQcSfr5K4XBHfNVG1Ed3jvcDYOmes1IH6gZnhAJT Y8gm7UrXUz6aIDR32pDhfEwK+4oYQPQNweWjWyBo= X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on semantical.co.uk X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS autolearn=ham autolearn_force=no version=3.4.2 References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <87a610wyod.fsf@masteringemacs.org> <875ybnwm2r.fsf@masteringemacs.org> <8A0520AE-7C8C-43D2-BE93-E80D5CC8856C@gmail.com> User-agent: mu4e @VERSION@; emacs 30.0.50 From: Mickey Petersen To: Yuan Fu Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Date: Mon, 27 Feb 2023 14:29:52 +0000 Organization: Mastering Emacs In-reply-to: <8A0520AE-7C8C-43D2-BE93-E80D5CC8856C@gmail.com> Message-ID: <871qmbw55n.fsf@masteringemacs.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LO2GBR01FT034:EE_|CWXP265MB2184:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 0f506bcd-df1b-4877-1e17-08db18cf682a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: d0HTZCPbnvByml6AvnCPSanZ3tQ1PTWk77Cl4dQa53S0vEIeU3RZPnq3c+Zc4YkmbXWNYBQAl9vl4xNUTvs7V7muHuZM+vk2zarHAc7oyujrfgh0g6YXVM5krXYHBNPX03tRYESNk2gEZFW2ysxWzYEs5Du3Z9jd1SdFlcJSf9ftZuTI1qcP4UWB6wuyFETj5cpLUjAY895RIwyC6Z+UeBBZ/YMtyk2unay3w9N5a6STyKuX1aSQM2fjnNret7e97T6jApbdjvUjRJvzrEZyCo7mixyAOMo/XV8QwxEdRt70NPxb5m7bIl+krRQ2LiNSsTRlYnM8a6XjYF+OffU+Sj8pM67miEdV9KbTbdAE0FyPYNKtvzOicrixzv/6vLPJMckpeqnbszDFtkv96clLvFxc6YhoSEqRFLMYGquYcQblQ4GmCjLRyMRNTDXbkODWLDCQoWjN0XJ1Q+pDZhk9xHfr2ZBFdNXmH0UlCr5xWxJajUS4aSQYMFH9bp20qlInS9QXpTrJGcHJ8Khdfnuf4FGNArNX/Ctjq5WGT9KSriyXc1oi1MUl4tEKM4c6TbNWjRffGn0XKfev7UWw9stNKXF0z4LM6Ej9I8y8Bl9DiPtAzck2m/kZx2d1M4Zh6H37MMik7JqrV7b31S2sWuSsO/BMK0Xoq4jvDIaVLka4BOqDosCo/l2aLRVTg7U6pILvz5bYmbxzHZe0RyTKlT2ykKjHbZ1fKCtSZB0Y60qBhqBvQihIO1zxsH/yE9mbM5OW X-Forefront-Antispam-Report: CIP:178.79.136.144; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:semantical.co.uk; PTR:semantical.co.uk; CAT:NONE; SFS:(13230025)(39830400003)(376002)(396003)(136003)(346002)(451199018)(36840700001)(46966006)(478600001)(36916002)(2616005)(336012)(47076005)(6266002)(54906003)(42186006)(186003)(53546011)(26005)(316002)(6666004)(107886003)(70206006)(70586007)(83380400001)(8676002)(4326008)(41300700001)(356005)(6862004)(5660300002)(8936002)(7596003)(7636003)(36860700001)(36756003)(86362001)(40480700001)(82310400005)(2906002)(38230200001)(79816003)(14776008); DIR:OUT; SFP:1102; X-OriginatorOrg: masteringemacs.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2023 14:32:08.7476 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f506bcd-df1b-4877-1e17-08db18cf682a X-MS-Exchange-CrossTenant-Id: a4e27e3d-bab0-45e8-8942-e64cf9fbd34f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a4e27e3d-bab0-45e8-8942-e64cf9fbd34f; Ip=[178.79.136.144]; Helo=[semantical.co.uk] X-MS-Exchange-CrossTenant-AuthSource: LO2GBR01FT034.eop-gbr01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWXP265MB2184 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Po Lu , Eli Zaretskii , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Yuan Fu writes: >> On Feb 27, 2023, at 12:22 AM, Mickey Petersen wrote: >> >> >> Yuan Fu writes: >> >>>> On Feb 26, 2023, at 1:41 AM, Mickey Petersen wrote: >>>> >>>> >>>> Yuan Fu 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=E2=80=99s product, tree-sit= ter >>> itself doesn=E2=80=99t mark a node outdated. It is possible for Emacs t= o not >>> delete the old tree and give it to you, or allow you to access >>> information of an outdated node. >> >> OK, so let me explain: >> >> Touching the buffer for any reason invalidates the whole tree; that's >> not good. It's not good, because a lot of the information may still be >> useful and viable. Outdating the node is not a bad idea as it avoids a >> lot of 'traps' around accidental modifications that can corrupt things >> without the developer's knowledge. >> >> I'd like to be able to access all the information possible; perhaps >> behind a flag variable like `treesit-allow-outdated-node-access'. What >> I'm really mostly interested in is: >> >> - How well the node references handle changes in byte positions in TS. > > They don=E2=80=99t handle position changes. If the buffer content changed= , we > need to reparse. Once we reparsed the buffer, a new tree is > born. While it is true that the new tree shares some node with the old > tree, tree-sitter does not expose any function or information that > tells you which node in the new tree is =E2=80=9Cthe same=E2=80=9D as whi= ch node in > the old tree; nor does it tell you whether a node in the old tree > still =E2=80=9Cexists=E2=80=9D in the new tree. > > Now, there does exist a function (in tree-sitter=E2=80=99s API) that allo= ws > you to =E2=80=9Cedit=E2=80=9D a node with position changes. But a) I=E2= =80=99m not sure how > does it handle the case where the node is deleted by the change and b) > it is not very useful because once you reparse the buffer, the new > tree is completely independent from the old tree (ignoring the > implementation detail which is not exposed). > >> >> - Does changing something at X shift (like a `point-marker`) everything >> below it? Does an outdated node correctly reference its new location >> and state, such as changes to children or its position in the tree? > > Like I said above, any buffer change will create a new tree with no relat= ion to the old tree, so there is no shifting. > > And there really isn=E2=80=99t a =E2=80=9Cnew location=E2=80=9D: we don= =E2=80=99t know if the old node > is still in the new tree. Mind you, even if the node is completely > outside of the changed region, it can still disappear from the new > tree because of change of its surrounding context. For example, in the > following C code: > > /* > int c =3D 1; > > If I insert a closing comment delimiter, and buffer becomes > > /* > int c =3D 1; > */ > > Even though int c =3D 1; is not in the changed range, nor did it=E2=80=99s > position move, all those nodes (int, c, =3D, etc) are not in the new > tree anymore, because the whole thing becomes a comment. > > I made any access to outdated nodes error because there really isn=E2=80= =99t > any good reason to use them, at least I didn=E2=80=99t think of any at the > time. And make them error out should help people catch errors. > >> >> Right now, Combobulate can make a proxy node, which essentially >> captures the basics of a live node and stores it in a defstruct. That >> way I can at least retain the start/end, type, text, etc. of a node >> and still do light refactoring without contorting myself to do things >> in a particular order, which is not always possible (like delaying >> editing to the very end.) > > IIUC, you want to do some very minor whitespace edit to the buffer > which doesn=E2=80=99t really change the parse tree, so you don=E2=80=99t = want the > nodes to be invalidated for no good reason? Not erroring on outdated > nodes is easy. As you said, we can add a > treesit-inhibit-error-outdated variable. But not it=E2=80=99s not so easy= to > automatically update outdated nodes=E2=80=99 positions (with aforemention= ed > tree-sitter function). However, if you are making those changes, you > much know how to adjust your nodes position, right? So maybe it isn=E2=80= =99t > a must-have for your purpose. It's a good point, but it's also easy to create a scenario where you at least want to keep the position and esp. the type and text (for reporting information to the user, or similar.) My main interest is now refactoring and how to best do it. If TS can do some of it, then all the better. I realise it was never meant to, but if we can continue accessing the information contained in a node even if it is outdated, then that could be useful, however niche. Currently I use overlays and point markers, but they are not infallible. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 27 17:37:43 2023 Received: (at 60237) by debbugs.gnu.org; 27 Feb 2023 22:37:43 +0000 Received: from localhost ([127.0.0.1]:49092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWm7q-00005y-H1 for submit@debbugs.gnu.org; Mon, 27 Feb 2023 17:37:43 -0500 Received: from mail-pj1-f51.google.com ([209.85.216.51]:54081) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWm7o-00005f-Cm for 60237@debbugs.gnu.org; Mon, 27 Feb 2023 17:37:41 -0500 Received: by mail-pj1-f51.google.com with SMTP id y2so7786740pjg.3 for <60237@debbugs.gnu.org>; Mon, 27 Feb 2023 14:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HUz4JZ+Ol4l4XcqGMwSX+6OThSiAxJDCilurvWsJnJE=; b=nl1c+wOQvoufgigC7ly3f6E4mpyoGFS08XaaP4Ootro0TnrBSNXmAjP9zfysdfacZl ycnqI5yq0QzdEUVzbYENGWLR2hcU5x1bFVWjHTaSgGhsj4T7gmXYQvsrD41w73wZApPT vur+p2btQ26fzhGZGkWT/JSya6f4YU5R0ynS9vGC9U0chdm+8jEVe7HKKTcJsakdx2cM D89fTmO5Y6wrEwGqFvhY2BdDHzKySwkHAa52nWSeoN2ElZ6SaunUzqBluMzAIqLUSQkq 7/kiDPmuWeZ8XgMY4qO7lNlfDrV2wbnRQfVo1vKa1ryvPLzyTM5HN6vMG8H0dSujM/Rz w5HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HUz4JZ+Ol4l4XcqGMwSX+6OThSiAxJDCilurvWsJnJE=; b=j3OV0G8D+OqJpymTzOnL/maNngohksjjpgCDtbu4wpFeEzxE/nBdISgdsJA1Fkw5UX LCHLytS3Qr79sVrhdKMadRMhzdOo32Hs1haQQZY8davGChSdYKsFEU5NLqgzUYyXQB4+ 1l6D7jAKZHAiZ2bwr1Cc7tKzEk+uvNrsgW1yXUz+JvdC2rDTcKf5/GqLzZvBwdvHQ2jb l8tEZiUpmjVXRTnZa0AkIpCqXkOo02ozmuKarHVE0iCf+jZnbwA0RdutpKBpmEaogeZw qkX0Vw1q4hpDMh10w4Uas03asI5C9eIdChotkqSMNcLLoiSzRRsOHT3i8ueFxx/ecDQn cvqg== X-Gm-Message-State: AO0yUKUfDpa41zifwnYRnc68Yyq+Vw8/fgdeUYdqg1l6OBJu3javeYwP VQdbhLhZRz64Z7zxp4x048s= X-Google-Smtp-Source: AK7set8BfEK0+bXuffahL4h2Bq98hdxw1tI4FIxqk5BNZM4bna/1VeeNJQHIt5W6mfcrW5qz3vUf4g== X-Received: by 2002:a17:902:7d94:b0:19d:135:2013 with SMTP id a20-20020a1709027d9400b0019d01352013mr534257plm.26.1677537454292; Mon, 27 Feb 2023 14:37:34 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id s22-20020a170902b19600b00198f9fa23a3sm5071167plr.287.2023.02.27.14.37.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2023 14:37:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node From: Yuan Fu In-Reply-To: <871qmbw55n.fsf@masteringemacs.org> Date: Mon, 27 Feb 2023 14:37:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4FF7BE3E-A966-4419-AA22-BAF57D1EF792@gmail.com> References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <87a610wyod.fsf@masteringemacs.org> <875ybnwm2r.fsf@masteringemacs.org> <8A0520AE-7C8C-43D2-BE93-E80D5CC8856C@gmail.com> <871qmbw55n.fsf@masteringemacs.org> To: Mickey Petersen X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Po Lu , Eli Zaretskii , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Feb 27, 2023, at 6:29 AM, Mickey Petersen = wrote: >=20 >=20 > Yuan Fu writes: >=20 >>> On Feb 27, 2023, at 12:22 AM, Mickey Petersen = wrote: >>>=20 >>>=20 >>> Yuan Fu writes: >>>=20 >>>>> On Feb 26, 2023, at 1:41 AM, Mickey Petersen = wrote: >>>>>=20 >>>>>=20 >>>>> Yuan Fu writes: >>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>=20 >>>>>>> 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? >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> What kind of exact interface (function) do you want? The >>>> treesit-node-outdated error is solely Emacs=E2=80=99s product, = tree-sitter >>>> itself doesn=E2=80=99t 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. >>>=20 >>> OK, so let me explain: >>>=20 >>> Touching the buffer for any reason invalidates the whole tree; = that's >>> not good. It's not good, because a lot of the information may still = be >>> useful and viable. Outdating the node is not a bad idea as it avoids = a >>> lot of 'traps' around accidental modifications that can corrupt = things >>> without the developer's knowledge. >>>=20 >>> I'd like to be able to access all the information possible; perhaps >>> behind a flag variable like `treesit-allow-outdated-node-access'. = What >>> I'm really mostly interested in is: >>>=20 >>> - How well the node references handle changes in byte positions in = TS. >>=20 >> They don=E2=80=99t handle position changes. If the buffer content = changed, we >> need to reparse. Once we reparsed the buffer, a new tree is >> born. While it is true that the new tree shares some node with the = old >> tree, tree-sitter does not expose any function or information that >> tells you which node in the new tree is =E2=80=9Cthe same=E2=80=9D as = which node in >> the old tree; nor does it tell you whether a node in the old tree >> still =E2=80=9Cexists=E2=80=9D in the new tree. >>=20 >> Now, there does exist a function (in tree-sitter=E2=80=99s API) that = allows >> you to =E2=80=9Cedit=E2=80=9D a node with position changes. But a) = I=E2=80=99m not sure how >> does it handle the case where the node is deleted by the change and = b) >> it is not very useful because once you reparse the buffer, the new >> tree is completely independent from the old tree (ignoring the >> implementation detail which is not exposed). >>=20 >>>=20 >>> - Does changing something at X shift (like a `point-marker`) = everything >>> below it? Does an outdated node correctly reference its new location >>> and state, such as changes to children or its position in the tree? >>=20 >> Like I said above, any buffer change will create a new tree with no = relation to the old tree, so there is no shifting. >>=20 >> And there really isn=E2=80=99t a =E2=80=9Cnew location=E2=80=9D: we = don=E2=80=99t know if the old node >> is still in the new tree. Mind you, even if the node is completely >> outside of the changed region, it can still disappear from the new >> tree because of change of its surrounding context. For example, in = the >> following C code: >>=20 >> /* >> int c =3D 1; >>=20 >> If I insert a closing comment delimiter, and buffer becomes >>=20 >> /* >> int c =3D 1; >> */ >>=20 >> Even though int c =3D 1; is not in the changed range, nor did it=E2=80=99= s >> position move, all those nodes (int, c, =3D, etc) are not in the new >> tree anymore, because the whole thing becomes a comment. >>=20 >> I made any access to outdated nodes error because there really = isn=E2=80=99t >> any good reason to use them, at least I didn=E2=80=99t think of any = at the >> time. And make them error out should help people catch errors. >>=20 >>>=20 >>> Right now, Combobulate can make a proxy node, which essentially >>> captures the basics of a live node and stores it in a defstruct. = That >>> way I can at least retain the start/end, type, text, etc. of a node >>> and still do light refactoring without contorting myself to do = things >>> in a particular order, which is not always possible (like delaying >>> editing to the very end.) >>=20 >> IIUC, you want to do some very minor whitespace edit to the buffer >> which doesn=E2=80=99t really change the parse tree, so you don=E2=80=99= t want the >> nodes to be invalidated for no good reason? Not erroring on outdated >> nodes is easy. As you said, we can add a >> treesit-inhibit-error-outdated variable. But not it=E2=80=99s not so = easy to >> automatically update outdated nodes=E2=80=99 positions (with = aforementioned >> tree-sitter function). However, if you are making those changes, you >> much know how to adjust your nodes position, right? So maybe it = isn=E2=80=99t >> a must-have for your purpose. >=20 > It's a good point, but it's also easy to create a scenario where you > at least want to keep the position and esp. the type and text (for > reporting information to the user, or similar.) I should be clearer. I meant that treesit-inhibit-error-outdated is = reasonable and easy to implement. So if you want we can add it. OTOH = auto-updating outdated nodes with position information is nontrivial, = and might not be must-have for your purpose. >=20 > My main interest is now refactoring and how to best do it. If TS can > do some of it, then all the better. I realise it was never meant to, > but if we can continue accessing the information contained in a node > even if it is outdated, then that could be useful, however niche. I guess =E2=80=9Crefactoring=E2=80=9D includes not only whitespace = changes but also some structural changes like slurping (or whatever = it=E2=80=99s called), right? If you want to do structural changes, = tree-sitter probably can=E2=80=99t help you much, as you observed. Maybe = it=E2=80=99s better to =E2=80=9Cexport=E2=80=9D the tree-sitter tree to = your own tree and do transformations with it? Maybe that=E2=80=99s = already what you does now. > Currently I use overlays and point markers, but they are not > infallible. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 27 17:46:01 2023 Received: (at 60237) by debbugs.gnu.org; 27 Feb 2023 22:46:02 +0000 Received: from localhost ([127.0.0.1]:49139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWmFt-0000Mn-Dk for submit@debbugs.gnu.org; Mon, 27 Feb 2023 17:46:01 -0500 Received: from mail-ed1-f48.google.com ([209.85.208.48]:38544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWmFr-0000MR-Ba for 60237@debbugs.gnu.org; Mon, 27 Feb 2023 17:45:59 -0500 Received: by mail-ed1-f48.google.com with SMTP id cy6so32324280edb.5 for <60237@debbugs.gnu.org>; Mon, 27 Feb 2023 14:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=hwiXOLj0M6SIWBuVe0lwH7wA3vC5a+CZidRakLvMiTc=; b=ezuLBoORC18aRnvNK5ToBN9FKNm0ZNs5vYu0wuYSR+bCBjWCQmlnq5xlySItQZbXj9 SeAozDjoM5BSSGX7ZneWFKLVUKPGd/fpAwKMlwzRFWzTid2sxTsyNluNBkGjGKqN9cI4 oFWJLAgX0cAmE8Fb5muYg898WqENYQjfcjdjgxUR8HhaB/5uGEdUjL61LcXBlJx4M/OQ waqm6k5dggY5BOVPav4z6ujyPSl+QGZG1KVDLi1Yk8DdSV4R9S89OGDG8DNsrTWIiSP6 0qukbDRqp4++abMCgSZFkMIsmBgJtTQ0l53ZBngFemY3klDJ01VLOZ/wI+u015EMEiCM IAZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hwiXOLj0M6SIWBuVe0lwH7wA3vC5a+CZidRakLvMiTc=; b=McLi2TLs3pxJ7Lg1lWeQAyh6aIEhSoJbyIRWOmzcqbv0OnrPxg1AtZqoKI0wiQN4eY hsWFyp0jmzHNLU4YT5ScFumripqvuty4AtTQwxRZS/9FiZxTYglkuw6N0dDcDbd5G2jM AdhXdaxUHnf5vmx4qAmh14/iPV11/09QCYlCavknktibF8QCosb8wJotISKrcbfwiECj q9DCFg7ipGPE2E/wveZ+737JAAn3IlpvDGavgFDxFpRp3BL9E6/7jRkB4Zc9QRznZIrY V8QqPWGG98kdQlJFKWCVM15NYyqIDPRYC7D5/aDtXRY3z0fape0v5uKqfcPRfUPQBoU7 Bo/w== X-Gm-Message-State: AO0yUKWDx3b+ZI94YoAIiZjKKVz3QAZ5EXTw494wYICMqQc1aTF8lGEm vcOjHaCvNLbiOULQDByB6WI= X-Google-Smtp-Source: AK7set+rVaBbQYWcx/V3Qp2U4bfZorMSWOd7zAL1lPogb2t18+rCimQc9RRrY6yN5SBuJwmnYvxVbg== X-Received: by 2002:aa7:d6c7:0:b0:4ad:828b:970 with SMTP id x7-20020aa7d6c7000000b004ad828b0970mr1031330edr.33.1677537953433; Mon, 27 Feb 2023 14:45:53 -0800 (PST) Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id z27-20020a50cd1b000000b004af516b5010sm3622259edi.94.2023.02.27.14.45.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Feb 2023 14:45:53 -0800 (PST) Message-ID: Date: Tue, 28 Feb 2023 00:45:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Content-Language: en-US To: Yuan Fu , Mickey Petersen References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <87a610wyod.fsf@masteringemacs.org> <875ybnwm2r.fsf@masteringemacs.org> <8A0520AE-7C8C-43D2-BE93-E80D5CC8856C@gmail.com> <871qmbw55n.fsf@masteringemacs.org> <4FF7BE3E-A966-4419-AA22-BAF57D1EF792@gmail.com> From: Dmitry Gutov In-Reply-To: <4FF7BE3E-A966-4419-AA22-BAF57D1EF792@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.9 (/) X-Debbugs-Envelope-To: 60237 Cc: Po Lu , Eli Zaretskii , 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 28/02/2023 00:37, Yuan Fu wrote: >> My main interest is now refactoring and how to best do it. If TS can >> do some of it, then all the better. I realise it was never meant to, >> but if we can continue accessing the information contained in a node >> even if it is outdated, then that could be useful, however niche. > I guess “refactoring” includes not only whitespace changes but also some structural changes like slurping (or whatever it’s called), right? If you want to do structural changes, tree-sitter probably can’t help you much, as you observed. Maybe it’s better to “export” the tree-sitter tree to your own tree and do transformations with it? Maybe that’s already what you does now. > Or simply produce all the editing information up front, and then modify the buffer in different places in one swoop. Just like treesit-indent-region does. That almost the same as described, but doesn't require creating a parallel parse tree hierarchy. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 09:01:02 2023 Received: (at 60237) by debbugs.gnu.org; 28 Feb 2023 14:01:02 +0000 Received: from localhost ([127.0.0.1]:49976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX0XO-0000W0-23 for submit@debbugs.gnu.org; Tue, 28 Feb 2023 09:01:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX0XM-0000Va-J0 for 60237@debbugs.gnu.org; Tue, 28 Feb 2023 09:01:01 -0500 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 1pX0XG-0006fy-JA; Tue, 28 Feb 2023 09:00:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=B2yIzKWsU5jImyV+93CGNGPFE5ma9F2dx0C6DIBvqKI=; b=TEdsgbx8O91I ngL5E+6WGamWYpRWFCnEJzc0S3lRDO7oxFYuTgJqSTzyPCGNxjeOePbw99enKQzciUnytKbjbc2c8 H1V9EL4Rx1TQfip7eL0eOWX0azv6PaKAK/6Zc+K5BZNQygGrUWpuF380sSnaylVoT0lJggNuUeI02 p3fcJnnY4mDpKU8kYvo/h8hL3yP2jhzi9bTvS7QopCleKWNCmoggdbOymtfiXNB0up9iHA2IWOKBB RnrduUb87JYW5/b6LGEk77X1vEQ4EF9TGpOMGAQjSXWuQwKKtQnoLtYqGPDQJjpUWTWZHLuCs3iO/ zLhD3QBl8n8CGnXD3STBcw==; 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 1pX0Wl-00060q-W4; Tue, 28 Feb 2023 09:00:40 -0500 Date: Tue, 28 Feb 2023 16:00:34 +0200 Message-Id: <83a60xhou5.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sun, 26 Feb 2023 10:16:25 -0500) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Yuan Fu , luangruo@yahoo.com, > mickey@masteringemacs.org, 60237@debbugs.gnu.org > Date: Sun, 26 Feb 2023 10:16:25 -0500 > > > Stefan, could it be a problem for us if garbage-collecting an object > > calls xmalloc? Including if the "memory" profiler is running at the > > time of that GC? > > I can't think of a fundamental reason why this would be a problem, but > as you've seen some code may not be quite ready for it. > > I suspect the simplest solution is to do something like what we do > for the cpu-profiler, i.e. handle the "time within GC" specially by > checking (EQ (backtrace_top_function (), QAutomatic_GC)) to determine > that we're within the GC. Any reason not to install the patch that uses gcsize instead of ASIZE? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 23:07:58 2023 Received: (at 60237) by debbugs.gnu.org; 1 Mar 2023 04:07:58 +0000 Received: from localhost ([127.0.0.1]:52373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXDkz-00074y-N3 for submit@debbugs.gnu.org; Tue, 28 Feb 2023 23:07:58 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXDky-00074h-0p for 60237@debbugs.gnu.org; Tue, 28 Feb 2023 23:07:56 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 43D3D80223; Tue, 28 Feb 2023 23:07:50 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CA4768001C; Tue, 28 Feb 2023 23:07:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677643668; bh=3qGlCunLQrXpHSAtdlhKBRKlX6+EuZybAPM+5CjzkVs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WWYG8S9d4X7RVxO44eiUwwYLrVw8XZ4k1RIuLBiqbaw3jrP6JkMHTavs8wuRCq3ng NsMS/I9zqtIvyqNidMTrz81NG8b47GBEkPCUR170o4/glsmbw904JxFe1zuP3FlyF9 9PcEIf8szNfTa0ZwmH84Jmfih4PYBzS1PbTmQFI7sXZ/zvnOMAUTcxJV70saocsLQ+ N210Dej9ttDC+n8gsA6pqb4YNv3ww9GjUXdddtkBhfUhwNEfmq2JI/of5d9oLehs7/ NKzaPAUuArB5Oji7brGPnIQEZ5oUYuLUvZv89Ot/+JvtFbjj6gfMb5W78YFVXhPeHv RXm0lNHYddr0w== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 83548121071; Tue, 28 Feb 2023 23:07:48 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <83a60xhou5.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 Feb 2023 16:00:34 +0200") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> Date: Tue, 28 Feb 2023 23:07:47 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.054 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> > Stefan, could it be a problem for us if garbage-collecting an object >> > calls xmalloc? Including if the "memory" profiler is running at the >> > time of that GC? >> >> I can't think of a fundamental reason why this would be a problem, but >> as you've seen some code may not be quite ready for it. >> >> I suspect the simplest solution is to do something like what we do >> for the cpu-profiler, i.e. handle the "time within GC" specially by >> checking (EQ (backtrace_top_function (), QAutomatic_GC)) to determine >> that we're within the GC. > > Any reason not to install the patch that uses gcsize instead of ASIZE? That might work, but I suspect there's a good reason why I used `cpu_gc_count`. I think running the "normal" profiling code during GC can cause other problems than just ASIZE because it can/will change ELisp objects, and modifying the heap while we're doing GC is the problem that concurrent GCs try to solve: our GC is not equipped for that. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 08:27:25 2023 Received: (at 60237) by debbugs.gnu.org; 1 Mar 2023 13:27:25 +0000 Received: from localhost ([127.0.0.1]:53004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXMUO-0001a3-Pe for submit@debbugs.gnu.org; Wed, 01 Mar 2023 08:27:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXMUN-0001Zq-51 for 60237@debbugs.gnu.org; Wed, 01 Mar 2023 08:27:23 -0500 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 1pXMUG-0003WX-Kw; Wed, 01 Mar 2023 08:27:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Buw+FWu6Y4em648Ykoo3+WufzUD4GCn29nD0vSa63WA=; b=FAaI2TxZyU4+ W+pr2A0p4Uv7KR1jOvADtnZLDkQ5/r9K8+tE6u0MljqbGNU7YLe4W+kpo1HbBs569kmDEMhNFIA7o GdJvEEQILemFIXN8aAlaDOdT6kJ1eR9Q1cZh19NUIFP8Z6X57kYd/Hwoazw5vje938BxOJVLre+Tv fCquaRBtr3oxk0yVCYHNnGNjqVK15jJ+/IiQX+XSqCPaFwtaEEDFW6lmeX1MAjMItQ35j8h+Llum8 FIPryszTdU0NYY8dGtod/cVu4gSqp7Fvb7QVQoOBpPiGWGnO15Ah1wdin3M/FwwY5mKi7mFCz2P89 z2siemBHD4nZb60utJ+9eA==; 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 1pXMUD-0001E2-7d; Wed, 01 Mar 2023 08:27:16 -0500 Date: Wed, 01 Mar 2023 15:27:26 +0200 Message-Id: <83mt4wfvpd.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Tue, 28 Feb 2023 23:07:47 -0500) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: casouri@gmail.com, luangruo@yahoo.com, mickey@masteringemacs.org, > 60237@debbugs.gnu.org > Date: Tue, 28 Feb 2023 23:07:47 -0500 > > >> > Stefan, could it be a problem for us if garbage-collecting an object > >> > calls xmalloc? Including if the "memory" profiler is running at the > >> > time of that GC? > >> > >> I can't think of a fundamental reason why this would be a problem, but > >> as you've seen some code may not be quite ready for it. > >> > >> I suspect the simplest solution is to do something like what we do > >> for the cpu-profiler, i.e. handle the "time within GC" specially by > >> checking (EQ (backtrace_top_function (), QAutomatic_GC)) to determine > >> that we're within the GC. > > > > Any reason not to install the patch that uses gcsize instead of ASIZE? > > That might work, but I suspect there's a good reason why I used > `cpu_gc_count`. I think running the "normal" profiling code during GC > can cause other problems than just ASIZE because it can/will change > ELisp objects, and modifying the heap while we're doing GC is the > problem that concurrent GCs try to solve: our GC is not equipped > for that. Would you mind installing a change along these lines on the emacs-29 branch? I'm not familiar enough with profiler.c to experiment with its code on the release branch. TIA From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 09:08:13 2023 Received: (at 60237) by debbugs.gnu.org; 1 Mar 2023 14:08:13 +0000 Received: from localhost ([127.0.0.1]:53065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXN7t-0002nl-2S for submit@debbugs.gnu.org; Wed, 01 Mar 2023 09:08:13 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:52310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXN7r-0002nQ-IX for 60237@debbugs.gnu.org; Wed, 01 Mar 2023 09:08:12 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 269DB440C6E; Wed, 1 Mar 2023 09:08:06 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 81CC6440C54; Wed, 1 Mar 2023 09:08:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677679684; bh=P9X88bLft3a4WJAWLGRMmJqOlgabxDl9RgsH/8kmlj4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QikFytl+2OLtZlZpeh8VDEpsLGGzt/P0O8AwQo9YC1lbTPnqxCqzyw05ptkgZXQls CGKfoOByblnL5rUBVePPAbNGugnauT+erppRzTLHoFvPxABsuKFweFgFLDRI71+dQI Wd3Hz+AaU4tqNzaCRaSR/y/cytMZwOKUvBYZm45jmQ5bNEJyOpHu1/5Onp78Y3Oe96 G76/2MzVf01H0Y+zGbvbh9G7r4g582JEa5sBub9C8Rsm55batu6mXNRIobje7R3o8i GporKwhU1S8neXBWzrxzjpTqm65CVo+Us5SlWDaFjOW2U/PAd+9jUEbyz900nLR35a ccemx3fQUmjqA== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4F97A12323F; Wed, 1 Mar 2023 09:08:04 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <83mt4wfvpd.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 01 Mar 2023 15:27:26 +0200") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> Date: Wed, 01 Mar 2023 09:08:03 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.126 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii [2023-03-01 15:27:26] wrote: >> From: Stefan Monnier >> Cc: casouri@gmail.com, luangruo@yahoo.com, mickey@masteringemacs.org, >> 60237@debbugs.gnu.org >> Date: Tue, 28 Feb 2023 23:07:47 -0500 >> >> >> > Stefan, could it be a problem for us if garbage-collecting an object >> >> > calls xmalloc? Including if the "memory" profiler is running at the >> >> > time of that GC? >> >> >> >> I can't think of a fundamental reason why this would be a problem, but >> >> as you've seen some code may not be quite ready for it. >> >> >> >> I suspect the simplest solution is to do something like what we do >> >> for the cpu-profiler, i.e. handle the "time within GC" specially by >> >> checking (EQ (backtrace_top_function (), QAutomatic_GC)) to determine >> >> that we're within the GC. >> > >> > Any reason not to install the patch that uses gcsize instead of ASIZE? >> >> That might work, but I suspect there's a good reason why I used >> `cpu_gc_count`. I think running the "normal" profiling code during GC >> can cause other problems than just ASIZE because it can/will change >> ELisp objects, and modifying the heap while we're doing GC is the >> problem that concurrent GCs try to solve: our GC is not equipped >> for that. > > Would you mind installing a change along these lines on the emacs-29 > branch? I'm not familiar enough with profiler.c to experiment with > its code on the release branch. For `emacs-29` I suggest we just use the patch below which should circumvent the problem. Stefan diff --git a/src/profiler.c b/src/profiler.c index 81b5e7b0cf0..c99ed0a81a2 100644 --- a/src/profiler.c +++ b/src/profiler.c @@ -505,6 +505,8 @@ DEFUN ("profiler-memory-log", void malloc_probe (size_t size) { + if (EQ (backtrace_top_function (), QAutomatic_GC)) + return; /* bug#60237 */ eassert (HASH_TABLE_P (memory_log)); record_backtrace (XHASH_TABLE (memory_log), min (size, MOST_POSITIVE_FIXNUM)); } From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 10:51:38 2023 Received: (at 60237) by debbugs.gnu.org; 1 Mar 2023 15:51:38 +0000 Received: from localhost ([127.0.0.1]:54678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOjx-0000QB-Mu for submit@debbugs.gnu.org; Wed, 01 Mar 2023 10:51:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50008) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOjv-0000Pw-RT for 60237@debbugs.gnu.org; Wed, 01 Mar 2023 10:51:36 -0500 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 1pXOjp-0007Uy-AI; Wed, 01 Mar 2023 10:51:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=28294Q0SLhe3uSpdd/E1vgXndilS1nReMNvaeytouBY=; b=n2i1i3sYx80a WqfeNI1Wk1zLjvYZ/ECEznYkrBo8KQ5AlJxbBKpbglRw3Mk+W24z/YIiXIjTRjdBMTxwPha5JHdFx sTZ7B5nlIrk1dZtYW2yFvRCQ6OV5/z+gdNMBX8IAilQWhcdPzJZNNihZgHyNmsy+PM+YnVRHRZHRT vsN6FLaiKbsQSvzM4ldHuVM/WbQU4LTkkgrlxpj6lQaVytJqdRdNbf422z4TjiGsmjcHGtoA9iUDv V/aYivkCcavrTiPMov9yncf2lvc6JgOKE0isEdBJ8LvteL0SfQ9bar1LPPrU+x49dcB4IJXTVbB1e iCdacuY2zmzV0Kf5fsDSvg==; 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 1pXOjo-0003Is-PH; Wed, 01 Mar 2023 10:51:29 -0500 Date: Wed, 01 Mar 2023 17:51:42 +0200 Message-Id: <83fsaofp0x.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Wed, 01 Mar 2023 09:08:03 -0500) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: casouri@gmail.com, luangruo@yahoo.com, mickey@masteringemacs.org, > 60237@debbugs.gnu.org > Date: Wed, 01 Mar 2023 09:08:03 -0500 > > Eli Zaretskii [2023-03-01 15:27:26] wrote: > > > Would you mind installing a change along these lines on the emacs-29 > > branch? I'm not familiar enough with profiler.c to experiment with > > its code on the release branch. > > For `emacs-29` I suggest we just use the patch below which should > circumvent the problem. Fine with me, please install, and thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 12:39:13 2023 Received: (at 60237) by debbugs.gnu.org; 1 Mar 2023 17:39:13 +0000 Received: from localhost ([127.0.0.1]:54840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXQQ4-0003GP-Tm for submit@debbugs.gnu.org; Wed, 01 Mar 2023 12:39:13 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXQQ3-0003GD-Ov for 60237@debbugs.gnu.org; Wed, 01 Mar 2023 12:39:12 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6FC0B44104F; Wed, 1 Mar 2023 12:39:06 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2C0D644103D; Wed, 1 Mar 2023 12:39:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677692345; bh=8zm2k4wI0beBX3pDqsO3Q2pnE9CNotA/DuJ0d8F2nFA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kEoadhjPaz2SjTy0/5zwvl5NGzvlqnY5wgrIIFjFS89xNq6rrVnQPhBOyXwQMhsSQ /2IPiZmk8zd/51e7XTBo6UJPf4m5708ACqASaJTA+dyvmCT+WuxK71jmcooBatFtrZ zZ1L8WMbb0dXsYxjgidNoNe7n20qip4sbyrijNS73yNVZHcBWKFKpqy3fjgcpIKl0F HfSriY5QV5UvrQJdmr9odjt41AWNwS1qAcsiFIp4QToEs3VmDdwuMM4V+ti/SeBWUY giUQViab3ud0El4cxEPQxuzproj4qL0li4vXTYROFCqz/YIc0Vi0gUXYnDLoYRrQOk xuMfcdNQlAzEQ== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DF9651231FD; Wed, 1 Mar 2023 12:39:04 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <83fsaofp0x.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 01 Mar 2023 17:51:42 +0200") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> Date: Wed, 01 Mar 2023 12:39:03 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.122 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> For `emacs-29` I suggest we just use the patch below which should >> circumvent the problem. > > Fine with me, please install, and thanks. Thanks, pushed. Hopefully we can do a bit better on `master`, but I don't have time for it right now. Maybe someone else? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 02 00:54:10 2023 Received: (at 60237) by debbugs.gnu.org; 2 Mar 2023 05:54:10 +0000 Received: from localhost ([127.0.0.1]:55532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXbtJ-00089v-V9 for submit@debbugs.gnu.org; Thu, 02 Mar 2023 00:54:10 -0500 Received: from sonic303-20.consmr.mail.ne1.yahoo.com ([66.163.188.146]:41270) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXbtI-00089g-76 for 60237@debbugs.gnu.org; Thu, 02 Mar 2023 00:54:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677736442; bh=RI9xMVyfLY/gYSFWa+jpt6y/uMwsD44dPxgG+sZGsCY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=uHRkx+Eh0/Z0aYLbOCdI0UpxDbRtCzH44udRUjoXWDmScnl1ujoA7fVoIBml2ozb/ssyhw2YFm0nVnf1LJiI7uruixferCpOcXcVUkXt6K/w+vyql1R5BtHQapgI9jB5InzCt7CLPht0AOYOpHS77vr6AFPYhe7KmwDBX3NT/ke2XAJoBUIIWHeD/yuGILJe5K88dzDtaTMlPpB1XBKSGAuno/iLIgS7DQJZsSre73zwt95BVGy9RTXxX6gd06qwkY3BUONA0jYEQYcnZkoOMfMf/xW0swRrl4xkbvD9OIz0JSYsJ0X/+FE7tA7nYtanoittVFqTLEsAMEtQkeqS6Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677736442; bh=WtkcTIqo/62gEGNyRtlrrJpbqF0/QwQogpZxdbJP947=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=B4v7491Ky2N0kOyBo3NMUpH3PV09N/hdf6TMHLpvwks25zauRzjBivsix4V2azfQac0nYZxG/8IlAS4b/tmH3M2Q86EIABFbjobofAsOyeTnYhOBXA6FkmbB36r2i+ozvi0I/qzOr5NpNw54OHRKv0MkCfsg9MX72x71/eMTFA3KjALY69aZD5J4Js84DBcKC5VwyJdEFJDPHri2SRyDYadP3gw+ItkUlCdBWottm4wnYSlmGu48X3KO098/8U5G1UR9J6nU6ON97zyv1GURbFokXAivymG0HMNtHEb2tgpKHl/8U/DS/sUjgTZTvU1MzIHm7Qd/JiZQ58Ww0IsHaA== X-YMail-OSG: NjPRyZ0VM1mmi9WT2nIPkpaHnAhGGIbIcNNLldlxj8Aup2wZOJBNIMlce8IULM_ B6xw6Vw3hVQD2t7PH.7Gp7_NAOhIv8bb2O7.O.9dhjEfELLSS2YizuOaAKtBjUH2oq_JDTbaPKJW eVhnDi9ic4yF_6NtawN2HxR3ZJ0s41O96cOn3ZsBXYS3pQ.vOuUDHZcjBu.h_2AiTOfL16GAQiup DzOIEOHgwhQ7VbwKJO516.040zW9dxoD3A1e3sHnS4h8fivWKlZTsgdTQaj_ZOYNQW_PjyA1GF8P P8xt1U6OTP7b9uUrukjJEbcOlnM_AaVBpdkpCqjzeXm4n6uhMoooezKpWIUaOQu18kljNoRrQ_jp gAsiOerAblpNG4VjXmmZuQ0Gtraa9bx6cm28RaUif9Us8x2d.U62A3JBIYBVVaZPKP7PlgFFo0lc L0gvwgXbOx3VLgMi5_prJlpE54OUAWCB5DwKdhfMIfD69hE_K0G0dz6izgfryzyDbHO8NAkQ0ACO z6297mxKsa1lvUa1bktuJHRBO.BfbCy.NKj34cHEfEKUdFXg0A_mzFK9T7Oh4n1EwePi8K60MlXq hee9nd0pgq_SLofcfdyF9hLKLgaAIFm.bANFx8GGrj7AjKbsUI_V3Rd_3ABa3zevw6ezN4JVtrv0 1_lpYw3Rm8927K3RLr.Cf6DuH2EGs2T1BpIea.H2Mz7c1Td7Ofakqy5r1NqHvh.TFgZ37eetYl6o BcBHJ.tPMycDQiGQfz56ELkxGQ8.dYlpsfMhLSOXEfpP6Qo9Ps_HZGKDsoAr0UDB1EAquLsYqfK0 n1ykx3sSYUILRVneZDTO9keSsiUagXt_7EfZnO.6uikbkPRQEWhbqVyVuX4cXK24vhlCTcaA1kOn TdNHFiDz1TN2k9gZnyGeVw.QbXO2XXVYFkOK47r4CnnIFPpbsR8TKpBCkyGz54e7rdI617FICQXu js0LAO.ewe72a914o.avpRU5AbQEzpnGg7k0MTh7Z9RQkpWpzQ_ydevhsIFqCaQkbVav49ivJNEe hvIjTCV44CReLz1Lo_9HuyR6RcNwReXwTD8jd5stPmNFoN8txot0Y6mHT_1_INp9cMYn94tUh_sq qx9Wemd7x5TvXgKkAoixISkhhqw2GGsfMfN4jAEx8fswWl79PAY1HqA6k9Waa3hK9BbBsEhAqsdl 3WxO18nvFuVvX7UvhU.k3Vj6g6oP_Kas8CBE3h29JAJ3RFhhEUANQMe3kj90C9v3G0OnwurycSY6 TstJVGZ3h6pUYXkDKEG_ZyWNef4N7PpjiK7RyrfKUAbY8TGHOd1v5yV2lLNKnwWtK7HJsRTxvMf4 hib.P2rMICFJ64sFiLCVx0h_dcKZIwQall17F6AgntxtkAbf0Dg_W1fxeuWeJd591uER_8t3zvRW FN6eV0guxfPpBKzI8Z4EVjXQqdG4ew6.sqHyWB897iJ0C_tQ8a7Yd8UIBSwPlVLVrMO9mYLtLNqv HZrnc1_Lbh15iu10sBP0UC7Vf6YfLPdcgvqW3EQSKuoft8ZnWkQixOh5c6sSQjvOFWyUr5yzqiH1 uQPOfX840i3t2eWIsnLnAbEeR_7pa2PJiEv7KniXAqSiJcn89hbkCFDXbxDzuPy6V5Z8DmYH486m qkjf95V5v2FrLGDqeFcIEoXqZxl0OAUvnKlW8uFLiFOPtsncsJcA0ZzznwnQVuvV4yLX7lK7VKut hZOza8KfNJAc2lgIVdnvY6wZFru9qPf_QrxizNBaoqp_uKNtd.gK3IacbX0R0b54z1ZCGTItz6Ll 8LPywTOoe7RNAltodTj1JK_JDZLe4_j3PFKwqNW_zL2GnBOaqqX93Gleozru8i29TOKZ4ou7JzPw z5wILK20.qVxRDC7HEw6bzI.ywlwXvOcrY6XZd2dCi1vEmhp_PYw0NYYfEItuvAejKLn6Xe5d3b7 UCnqUeLUWwIg5UFLZs9ayxWOG_AoBQJON5JyHX.BYgOz7XXg_l8rUlgQdVM4dWAmsN4Yt5TNQadz UF1rCiksDutQvaVpg_5BFNscy87dQQyOMMwumH5Gbl_GFscOD9cOIbCh9J_flJZlS.vPM_dNPjc1 sQHPP845bB73DS0DMIW8B78opmzjFQL_DfD1JBSjm2QYTRq6tMkQ1WW.OS3t3h.kZ4znFVpplqzB 1SvIm5HE_02E0K2So7dnMwuCU69a7imUbQqsLL8lzFfM.ii1ujVy_I5h6K9cFb1qiaWML6nptdwR W3HlehrA5iDVL6TmXlpeI.K5KH9BfYOAB7u1Pnft6JixiCVGgIEmWyNxaXNgBq.ZY X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Thu, 2 Mar 2023 05:54:02 +0000 Received: by hermes--production-sg3-9fc5746c8-xxb6k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e4a26da21794c4421549a9f459ac3669; Thu, 02 Mar 2023 05:54:00 +0000 (UTC) From: Po Lu To: Stefan Monnier Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: (Stefan Monnier's message of "Wed, 01 Mar 2023 09:08:03 -0500") References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> Date: Thu, 02 Mar 2023 13:53:54 +0800 Message-ID: <871qm7zojx.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21221 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2178 X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 60237 Cc: Eli Zaretskii , mickey@masteringemacs.org, casouri@gmail.com, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > Eli Zaretskii [2023-03-01 15:27:26] wrote: > >>> From: Stefan Monnier >>> Cc: casouri@gmail.com, luangruo@yahoo.com, mickey@masteringemacs.org, >>> 60237@debbugs.gnu.org >>> Date: Tue, 28 Feb 2023 23:07:47 -0500 >>> >>> >> > Stefan, could it be a problem for us if garbage-collecting an object >>> >> > calls xmalloc? Including if the "memory" profiler is running at the >>> >> > time of that GC? >>> >> >>> >> I can't think of a fundamental reason why this would be a problem, but >>> >> as you've seen some code may not be quite ready for it. >>> >> >>> >> I suspect the simplest solution is to do something like what we do >>> >> for the cpu-profiler, i.e. handle the "time within GC" specially by >>> >> checking (EQ (backtrace_top_function (), QAutomatic_GC)) to determine >>> >> that we're within the GC. >>> > >>> > Any reason not to install the patch that uses gcsize instead of ASIZE? >>> >>> That might work, but I suspect there's a good reason why I used >>> `cpu_gc_count`. I think running the "normal" profiling code during GC >>> can cause other problems than just ASIZE because it can/will change >>> ELisp objects, and modifying the heap while we're doing GC is the >>> problem that concurrent GCs try to solve: our GC is not equipped >>> for that. >> >> Would you mind installing a change along these lines on the emacs-29 >> branch? I'm not familiar enough with profiler.c to experiment with >> its code on the release branch. > > For `emacs-29` I suggest we just use the patch below which should > circumvent the problem. > > > Stefan > > > diff --git a/src/profiler.c b/src/profiler.c > index 81b5e7b0cf0..c99ed0a81a2 100644 > --- a/src/profiler.c > +++ b/src/profiler.c > @@ -505,6 +505,8 @@ DEFUN ("profiler-memory-log", > void > malloc_probe (size_t size) > { > + if (EQ (backtrace_top_function (), QAutomatic_GC)) > + return; /* bug#60237 */ > eassert (HASH_TABLE_P (memory_log)); > record_backtrace (XHASH_TABLE (memory_log), min (size, MOST_POSITIVE_FIXNUM)); > } Shouldn't this be: if (gc_in_progress) return; From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 02 15:24:19 2023 Received: (at 60237) by debbugs.gnu.org; 2 Mar 2023 20:24:19 +0000 Received: from localhost ([127.0.0.1]:58463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXpTO-0000Xk-St for submit@debbugs.gnu.org; Thu, 02 Mar 2023 15:24:19 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXpTN-0000XW-7Y for 60237@debbugs.gnu.org; Thu, 02 Mar 2023 15:24:17 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 65A0380087; Thu, 2 Mar 2023 15:24:11 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 54E81800AE; Thu, 2 Mar 2023 15:24:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677788649; bh=FNov4R2aFZSNzJCxWvbWjU+1og15giQk37Rna2gZzSw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AqgiBzeNrWlhTCdosiOmndZbYCS5T4q16vPIM2yXq1WmNfIf0cCW0i1rHyR792bn/ VPZLT0s+NqnpAKv1ilyosXWKcRE5jhBpTJarXHuzqC7PylV+H4Hig/ZUIPCpwN7voF 6WX6FvGZmz6bc5+KeSA7Y0Bd2xbPaPT/8TwtnLjoOHEe4/NnA+7HG56seB2bYl4bgG Fy/NSoNpJC6TclI+uccSPq/qCNnEx4JDUVj9SVr+Y9CLINySHWkfUzmCj6KE4NGcBl MAIT1wCM5hictLAbHD8ghif5M0odAKqCqoDcj/PGcAd1tLAstI7OyQbYdIWEZqEOYN 6pWcY3Syd1R0w== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 160DD123199; Thu, 2 Mar 2023 15:24:09 -0500 (EST) From: Stefan Monnier To: Po Lu Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <871qm7zojx.fsf@yahoo.com> (Po Lu's message of "Thu, 02 Mar 2023 13:53:54 +0800") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <871qm7zojx.fsf@yahoo.com> Date: Thu, 02 Mar 2023 15:24:07 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.051 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: Eli Zaretskii , mickey@masteringemacs.org, casouri@gmail.com, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> diff --git a/src/profiler.c b/src/profiler.c >> index 81b5e7b0cf0..c99ed0a81a2 100644 >> --- a/src/profiler.c >> +++ b/src/profiler.c >> @@ -505,6 +505,8 @@ DEFUN ("profiler-memory-log", >> void >> malloc_probe (size_t size) >> { >> + if (EQ (backtrace_top_function (), QAutomatic_GC)) >> + return; /* bug#60237 */ >> eassert (HASH_TABLE_P (memory_log)); >> record_backtrace (XHASH_TABLE (memory_log), min (size, MOST_POSITIVE_FIXNUM)); >> } > > Shouldn't this be: > > if (gc_in_progress) > return; Sounds like a good idea. If so that should apply to the cpu profiler code as well. It might be worthwhile to check the details to see if there might be subtle differences (e.g. when we're running `post-gc-hook` maybe?). Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 07:22:03 2023 Received: (at 60237) by debbugs.gnu.org; 4 Mar 2023 12:22:03 +0000 Received: from localhost ([127.0.0.1]:35344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYQtn-0001n7-11 for submit@debbugs.gnu.org; Sat, 04 Mar 2023 07:22:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYQtk-0001mV-2E for 60237@debbugs.gnu.org; Sat, 04 Mar 2023 07:22:01 -0500 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 1pYQte-0004d2-A5; Sat, 04 Mar 2023 07:21:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=eyUgG4u/0zna6SCkaOJemxlqA9MVVdMrBFWYm1aNmhI=; b=NizRzL9aHZls HUrxVMAX1vt3zmDPj7bgi/EKh+m8wByJlXyQEAUphstU81qkj9GkPkS/tbQEjL7lbATgBxSVFRukC 72QKt2nUCDedHnfism0+QpfC+dGrSUbL7AWZiTV2e1tIrIh3IqeJ97AQpeqvIeMZHN5iBGH88d7iJ 02/kjnRRPSC+2EJxBqgZ7ZrYkv1Q/YYzY5OhAOIWWWM46h0dMYOqeswHJC1vNWTkvUuukbWdH6LuF XsAHKVBE6Mzfyaecl6R9sCEidE/GEs/ymvrJTRNlHE/WKjivmyEejIQuLip1ME9mX1uAsMK78D1Xl iKDXWPEb0nS/W3GyQCz9HA==; 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 1pYQtd-0007AJ-PO; Sat, 04 Mar 2023 07:21:54 -0500 Date: Sat, 04 Mar 2023 14:21:41 +0200 Message-Id: <83v8jgaeqy.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Wed, 01 Mar 2023 12:39:03 -0500) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: casouri@gmail.com, luangruo@yahoo.com, mickey@masteringemacs.org, > 60237@debbugs.gnu.org > Date: Wed, 01 Mar 2023 12:39:03 -0500 > > >> For `emacs-29` I suggest we just use the patch below which should > >> circumvent the problem. > > > > Fine with me, please install, and thanks. > > Thanks, pushed. Hopefully we can do a bit better on `master`, but > I don't have time for it right now. Maybe someone else? I tried cargo-culting the cpu_gc_count stuff for the memory profiler, see the patch below. However, something is amiss: this assertion in profiler.el sometimes triggers: (maphash (lambda (backtrace _count) (let* ((max (1- (length backtrace))) (head (aref backtrace max)) (best-parent nil) (best-match (1+ max)) (parents (gethash head fun-map))) (pcase-dolist (`(,i . ,parent) parents) (when t ;; (<= (- max i) best-match) ;Else, it can't be better. (let ((match max) (imatch i)) (cl-assert (>= match imatch)) <<<<<<<<<<<<<<<<<<<<<<<<<<<< (cl-assert (function-equal (aref backtrace max) (aref parent i))) I cannot reliably reproduce this, and don't understand what causes the assertion. Any hints? Here's the patch: diff --git a/src/profiler.c b/src/profiler.c index 8247b2e..92d8a0a 100644 --- a/src/profiler.c +++ b/src/profiler.c @@ -227,6 +227,9 @@ record_backtrace (log_t *log, EMACS_INT count) /* Separate counter for the time spent in the GC. */ static EMACS_INT cpu_gc_count; +/* Separate counter for the memory allocations during GC. */ +static EMACS_INT mem_gc_count; + /* The current sampling interval in nanoseconds. */ static EMACS_INT current_sampling_interval; @@ -451,7 +454,10 @@ DEFUN ("profiler-memory-start", Fprofiler_memory_start, Sprofiler_memory_start, error ("Memory profiler is already running"); if (NILP (memory_log)) - memory_log = make_log (); + { + mem_gc_count = 0; + memory_log = make_log (); + } profiler_memory_running = true; @@ -495,6 +501,10 @@ DEFUN ("profiler-memory-log", more for our use afterwards since we can't rely on its special pre-allocated keys anymore. So we have to allocate a new one. */ memory_log = profiler_memory_running ? make_log () : Qnil; + Fputhash (make_vector (1, QAutomatic_GC), + make_fixnum (mem_gc_count), + result); + mem_gc_count = 0; return result; } @@ -506,10 +516,19 @@ DEFUN ("profiler-memory-log", malloc_probe (size_t size) { if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */ - /* FIXME: We should do something like what we did with `cpu_gc_count`. */ - return; - eassert (HASH_TABLE_P (memory_log)); - record_backtrace (XHASH_TABLE (memory_log), min (size, MOST_POSITIVE_FIXNUM)); + /* Special case the malloc-count inside GC because the hash-table + code is not prepared to be used while the GC is running. + More specifically it uses ASIZE at many places where it does + not expect the ARRAY_MARK_FLAG to be set. We could try and + harden the hash-table code, but it doesn't seem worth the + effort. */ + mem_gc_count = saturated_add (mem_gc_count, 1); + else + { + eassert (HASH_TABLE_P (memory_log)); + record_backtrace (XHASH_TABLE (memory_log), + min (size, MOST_POSITIVE_FIXNUM)); + } } DEFUN ("function-equal", Ffunction_equal, Sfunction_equal, 2, 2, 0, From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 08 11:34:34 2023 Received: (at 60237) by debbugs.gnu.org; 8 Mar 2023 16:34:34 +0000 Received: from localhost ([127.0.0.1]:50048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZwkM-0000vj-DC for submit@debbugs.gnu.org; Wed, 08 Mar 2023 11:34:34 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZwkJ-0000vP-Ms for 60237@debbugs.gnu.org; Wed, 08 Mar 2023 11:34:32 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 764931000BD; Wed, 8 Mar 2023 11:34:25 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C3521100054; Wed, 8 Mar 2023 11:34:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1678293263; bh=9YQBIQNv7Lhd3UQTHhyb1vtF0h3ImGHygBLwyt2x9jM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=k3ExxyS+ko3gY+e7FdbA2nT9gROFPyI1VTEYm3f00qoCjWOFOV9AexN9gYfO7HRLA VzkFx+lCF2wyrUOS1gvoMZjn760/jozMLfylip+R2tLho/1FJTZsCjCs9kYmhjmWUR tdWTGJ02RXzrNbVU2gl9dfplMikW71KtdnBw3TjyMwmxpPZscgYvF6qJuCZNL6QeBq ilutAKrhOxEzacXB7FvtGcGAi6d78qupNBfxCdhDf/7NeblViFYUsgRmLkxHiMKvQu qql5pEFDCoNu/CRWdmx6Jy3S9mHyWfEAoxbETl4Tpm/UUOx0HyPvMC8D9qjP2Hjnme yzVdSKqIRrKDQ== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 070C812327D; Wed, 8 Mar 2023 11:34:23 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <83v8jgaeqy.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 Mar 2023 14:21:41 +0200") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> <83v8jgaeqy.fsf@gnu.org> Date: Wed, 08 Mar 2023 11:34:14 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.020 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I tried cargo-culting the cpu_gc_count stuff for the memory profiler, > see the patch below. However, something is amiss: this assertion in > profiler.el sometimes triggers: > > (maphash > (lambda (backtrace _count) > (let* ((max (1- (length backtrace))) > (head (aref backtrace max)) > (best-parent nil) > (best-match (1+ max)) > (parents (gethash head fun-map))) > (pcase-dolist (`(,i . ,parent) parents) > (when t ;; (<= (- max i) best-match) ;Else, it can't be better. > (let ((match max) > (imatch i)) > (cl-assert (>= match imatch)) <<<<<<<<<<<<<<<<<<<<<<<<<<<< > (cl-assert (function-equal (aref backtrace max) > (aref parent i))) > > I cannot reliably reproduce this, and don't understand what causes the > assertion. Any hints? Hmm... I just took a look but can't see neither why your change would be more likely to trigger this error than the existing code for the `cpu` case, nor why this assertion should always be true. IOW, I'm going to have to find the original author to ask him what he was thinking back then. > Here's the patch: Looks good. Just one nitpick: > malloc_probe (size_t size) > { > if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */ > - /* FIXME: We should do something like what we did with `cpu_gc_count`. */ > - return; > - eassert (HASH_TABLE_P (memory_log)); > - record_backtrace (XHASH_TABLE (memory_log), min (size, MOST_POSITIVE_FIXNUM)); > + /* Special case the malloc-count inside GC because the hash-table > + code is not prepared to be used while the GC is running. > + More specifically it uses ASIZE at many places where it does > + not expect the ARRAY_MARK_FLAG to be set. We could try and > + harden the hash-table code, but it doesn't seem worth the > + effort. */ > + mem_gc_count = saturated_add (mem_gc_count, 1); Here we should increase by `size` rather than by 1. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 10 13:28:29 2023 Received: (at 60237) by debbugs.gnu.org; 10 Mar 2023 18:28:29 +0000 Received: from localhost ([127.0.0.1]:55865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pahTh-0005I5-96 for submit@debbugs.gnu.org; Fri, 10 Mar 2023 13:28:29 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pahTg-0005Hr-Dz for 60237@debbugs.gnu.org; Fri, 10 Mar 2023 13:28:28 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BC4DF1000BD; Fri, 10 Mar 2023 13:28:22 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2495510009E; Fri, 10 Mar 2023 13:28:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1678472901; bh=1qB58S5PowsNUOOC/xGuhE+6BysUsR2sMFcqEU0NrQE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=U1SnFXKTjN81ltSZqUHb7VIuIy/Ayw0bE9gIqlgQpHHQmqPfaJyMH8JORdvSoyWOf do52adA//EpB1q1gXm8HvZcYPKLRe2T5doh+GSNEm7b0hy+8vFgBmzJnhUY4ClfbOh zgLxZgHhSHIvoR3nYEbL3fGvgXlzynKENFdWU5AHqewq0y/8hnxjZA9ctJLUil/5Od 3lCh+QKqHZ7Z9yO3f/MUVZ+wTIsRaKSsPVsgltgDAthF4Hg3MzJHEozYLJDJ6JTSaN lgLWfYZ0x4c6ZUd+S20+aZPKTkNjmu1Eufgj3zXFLO7h2YMJSd1aLrAcGBDBgaXN0P aNRTUtN23re4A== Received: from ceviche (modemcable137.21-80-70.mc.videotron.ca [70.80.21.137]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EA51312324B; Fri, 10 Mar 2023 13:28:20 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: (Stefan Monnier's message of "Wed, 08 Mar 2023 11:34:14 -0500") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> <83v8jgaeqy.fsf@gnu.org> Date: Fri, 10 Mar 2023 13:28:20 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.238 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I tried cargo-culting the cpu_gc_count stuff for the memory profiler, >> see the patch below. However, something is amiss: this assertion in >> profiler.el sometimes triggers: >> >> (maphash >> (lambda (backtrace _count) >> (let* ((max (1- (length backtrace))) >> (head (aref backtrace max)) >> (best-parent nil) >> (best-match (1+ max)) >> (parents (gethash head fun-map))) >> (pcase-dolist (`(,i . ,parent) parents) >> (when t ;; (<= (- max i) best-match) ;Else, it can't be better. >> (let ((match max) >> (imatch i)) >> (cl-assert (>= match imatch)) <<<<<<<<<<<<<<<<<<<<<<<<<<<< >> (cl-assert (function-equal (aref backtrace max) >> (aref parent i))) >> >> I cannot reliably reproduce this, and don't understand what causes the >> assertion. Any hints? > > Hmm... I just took a look but can't see neither why your change would > be more likely to trigger this error than the existing code for the > `cpu` case, nor why this assertion should always be true. I can imagine corner cases where this could trigger, but they all involve funny business where we change `profiler-max-stack-depth` during a single profiling run (I think you'd need to write ad-hoc ELisp code for that). The only other explanation I can see is that we somehow end up with a backtrace that includes `Automatic_GC` somewhere not at the top (maybe this can happen with a `post-gc-hook`?). If you manage to reproduce it, I'd be interested to know the value of `backtrace` and `parent` when the assertion fails (and maybe just save the `log` hash-table so we can look at it). It might be a symptom of another bug. And I still can't see how/why this would happen only for the `memory` profiler and not for the `cpu` profiler, so I assume it can also happen for the `cpu` profiler and we've just been lucky not to bump into it yet. This said, I think the patch below should fix it for the `cpu` profiler and a similar change should fix it for your patch (and the patch is arguably right in the sense that without this `nil` entry, the backtrace entry created for `Automatic_GC` is not really complete). Stefan diff --git a/src/profiler.c b/src/profiler.c index 8247b2e90c6..295c47a2acd 100644 --- a/src/profiler.c +++ b/src/profiler.c @@ -423,7 +423,7 @@ DEFUN ("profiler-cpu-log", Fprofiler_cpu_log, Sprofiler_cpu_log, more for our use afterwards since we can't rely on its special pre-allocated keys anymore. So we have to allocate a new one. */ cpu_log = profiler_cpu_running ? make_log () : Qnil; - Fputhash (make_vector (1, QAutomatic_GC), + Fputhash (CALLN (Fvector, QAutomatic_GC, Qnil), make_fixnum (cpu_gc_count), result); cpu_gc_count = 0; From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 10 15:57:07 2023 Received: (at 60237) by debbugs.gnu.org; 10 Mar 2023 20:57:07 +0000 Received: from localhost ([127.0.0.1]:55974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pajnX-0001HH-9F for submit@debbugs.gnu.org; Fri, 10 Mar 2023 15:57:07 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pajnV-0001Go-SK for 60237@debbugs.gnu.org; Fri, 10 Mar 2023 15:57:06 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 24E621000BD; Fri, 10 Mar 2023 15:57:00 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 241EC10009E; Fri, 10 Mar 2023 15:56:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1678481818; bh=M5dhhG5ZXLWCacILZR/sEReQkvGdFUE3PDX2Ri1ReUw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MFSR4xDmlO9UOBgR6q9eVQDqvJcCGw52t/UEPt+t3Jx1qz4jwXiI5wj3m+4xgIcsn H23BMuX46FX+bgVdbgjBNQfaG/3yFB6sywXuL4YOALaGhOZ/+lHRMYnxhnOlGyRrzc zTK3JVw0DKj7+WyIe0fcneQvF6CQ9TgVfV/V83wgQ6IRYQJlCUNgqPkHrEbMSYO9+D 0b0hlvkRmEpJFVgwd/L2aPBnmyAi2VV/kocHK7PdWXB1UeR6A0IiEqLGz6tno0HNve U6Ks1sWvFzxLjBpdPzW61IsF8sI9OlLzmN2LgzO1wKyvVEKe3edgktfjbCCwFB5+gJ /9B/qUaJmRqYQ== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B8FD2120E8A; Fri, 10 Mar 2023 15:56:57 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: (Stefan Monnier's message of "Fri, 10 Mar 2023 13:28:20 -0500") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> <83v8jgaeqy.fsf@gnu.org> Date: Fri, 10 Mar 2023 15:56:56 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.059 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I pushed your change to `master`, with my patch on top. Plus a few other patches to reduce redundancy a bit and fix a FIXME. Stefan Stefan Monnier [2023-03-10 13:28:20] wrote: >>> I tried cargo-culting the cpu_gc_count stuff for the memory profiler, >>> see the patch below. However, something is amiss: this assertion in >>> profiler.el sometimes triggers: >>> >>> (maphash >>> (lambda (backtrace _count) >>> (let* ((max (1- (length backtrace))) >>> (head (aref backtrace max)) >>> (best-parent nil) >>> (best-match (1+ max)) >>> (parents (gethash head fun-map))) >>> (pcase-dolist (`(,i . ,parent) parents) >>> (when t ;; (<= (- max i) best-match) ;Else, it can't be better. >>> (let ((match max) >>> (imatch i)) >>> (cl-assert (>= match imatch)) <<<<<<<<<<<<<<<<<<<<<<<<<<<< >>> (cl-assert (function-equal (aref backtrace max) >>> (aref parent i))) >>> >>> I cannot reliably reproduce this, and don't understand what causes the >>> assertion. Any hints? >> >> Hmm... I just took a look but can't see neither why your change would >> be more likely to trigger this error than the existing code for the >> `cpu` case, nor why this assertion should always be true. > > I can imagine corner cases where this could trigger, but they all > involve funny business where we change `profiler-max-stack-depth` during > a single profiling run (I think you'd need to write ad-hoc ELisp code > for that). The only other explanation I can see is that we > somehow end up with a backtrace that includes `Automatic_GC` somewhere > not at the top (maybe this can happen with a `post-gc-hook`?). > > If you manage to reproduce it, I'd be interested to know the value of > `backtrace` and `parent` when the assertion fails (and maybe just save > the `log` hash-table so we can look at it). It might be a symptom of > another bug. > > And I still can't see how/why this would happen only for the `memory` > profiler and not for the `cpu` profiler, so I assume it can also happen > for the `cpu` profiler and we've just been lucky not to bump into it yet. > > This said, I think the patch below should fix it for the `cpu` profiler > and a similar change should fix it for your patch (and the patch is > arguably right in the sense that without this `nil` entry, the backtrace > entry created for `Automatic_GC` is not really complete). > > > Stefan > > > diff --git a/src/profiler.c b/src/profiler.c > index 8247b2e90c6..295c47a2acd 100644 > --- a/src/profiler.c > +++ b/src/profiler.c > @@ -423,7 +423,7 @@ DEFUN ("profiler-cpu-log", Fprofiler_cpu_log, Sprofiler_cpu_log, > more for our use afterwards since we can't rely on its special > pre-allocated keys anymore. So we have to allocate a new one. */ > cpu_log = profiler_cpu_running ? make_log () : Qnil; > - Fputhash (make_vector (1, QAutomatic_GC), > + Fputhash (CALLN (Fvector, QAutomatic_GC, Qnil), > make_fixnum (cpu_gc_count), > result); > cpu_gc_count = 0; From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 10 18:52:59 2023 Received: (at 60237) by debbugs.gnu.org; 10 Mar 2023 23:52:59 +0000 Received: from localhost ([127.0.0.1]:56142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pamXi-0000Ei-OZ for submit@debbugs.gnu.org; Fri, 10 Mar 2023 18:52:59 -0500 Received: from sonic308-10.consmr.mail.ne1.yahoo.com ([66.163.187.33]:33378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pamXf-0000EJ-UN for 60237@debbugs.gnu.org; Fri, 10 Mar 2023 18:52:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678492368; bh=9EjMTqXFVU3Jtz2AuAUuUUaOPKZNwG5u00L6xbFx+LE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=QZHy6n7aRdkXlOzW97g8IhB9rejHCw+E14VNZogM6StKvuLM47Q37gfvapImzcn0uP1yU+A5+ES8ZuvRnzdZ5PbUzLIeImSmabBL25XlqLDoYoKC3HLctemYtlQuxvX3IFYsr21VLNbenoNIrsy+a+3YrxVpV2hSpjOsZKDb+lHDOIRJjXTAJjE6xXEKEnFKNlnVSLcosUMG5goVf9WGKk+MNa+oIDM71aU4YkDB5IYpCOUsXsJhBO/eomzMoEpA+g2Fza6t1QyS1Gt7NPUwcpd6rRDecfNp70np3SXCrgInYn97W9Ubmk16YpuciMecngw4pJzivxiN3k4O9XIbTg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678492368; bh=S87FYlPZ+Ypo6eXLZceRLJsufAX3AEYyApXiVLuW2K/=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=fbw+pznPwcu8W2wfjAz6Jd/0GgEYJwsH9PSwk0gl2gDNY1fHtClDYSzfwBOdzNzhZBmLK7lheXyzzledLZNEiDqeynEFdQkgEN7nLh1WESvlEz8ZLukbUvLDELY2/2jwcsuKyIR/hyucTAI+wJUsZ1lMGmyZMcTyk25JgUj4/qosNE8NEs/rK77hTZvQyZQnjuZL0ZjJT0FxtO3TJeUPRbwMk4x/3TLFUcS/53unjA/zuldZA0Ob7G2y5pIQkM6e0l62oWGRkDcRcwXaC8EOAMXr1xwfvVsFJEVJUF6eW1pViLDn1K5RpsySyCSLZteQX/YIbNM3tEoAJ+Q7YXlUcA== X-YMail-OSG: YowuXOEVM1mxEwBbIM.jS1TgMUekX33q26.cnxg_e96PXAie9siPsUUiXCDgVj5 fmis1fDDkucMjCLso_lBDFc8LRreN0EopccgaqqQBbDZEWuqlBwT6ZwlYAAaxEcZj6JacwwrM_MR 8JPOwmI6z7XqSjzHcbP3DlHn2oIVxl8enJcW2jaiPFCIkivMx6H5A59apecqHBFDHpFEjfPXYZxu JL6woRVI_r34rpZgsuPndTdug8ABtH9DLnmuqpbXw0X2EGekPaKUU00cW3HnLrrOJmuosk3_goXU imgextTk47Jx5WMBrebWEif0aRd9XBfbvHY4offT5m3cthEeCivKsVG_BDw0AavPPMqvDoV21_LG 5A2R.bLtXREfnd_xygMZ2qsvr2kJMHfH11g6R8XhVLkI_J4Fp2tQc9NvwedC2POOdYhkE.5puBEl dJOAth4YK0bsss6smHuBtjbkhGG1SPz4jvPmIOTL5ItQvtLhNWT._t6YnxvuQwbnvzwac35wY3HE YFPNI9nMf0O5.74dSrXktG9jrouJIXwdimjBnsCBc_5qF_8ZB_mmhQVAoKTJ2pKrSDKNkji_4oEW wMRuhAUH5EBQDFlDaEmcymBDasN8gmUF6R9UvsAXkoHisLJ3b3I2rIoA8hW5PGwrfMSMTpk.TBHn Klkes2D0ueYKgP1ya8c12V8ev9jKtYj4TKJLQEVCAfJqsu6aCOnaKtgbqlg533GBBPDuqB9tBnHk zfW9mnacy2KtMycEXZTOdTzVu2N_sPCRLDjoKbzo4xNMTzugWFeaedLMItpzAQBwrYThCeJFiCRU MVyQTFrm5ocU6RFKblB.EOjG4ehYXyLmtBoXnsjvVFplkNIoVr9a.z.PyPshA86E4TciV8DOcaKD ARGIPCYEPhtImRkWUK9v.jfwz5tDpLbDxv1hOhmZflIg2uDaJFWmjdPLKKxpspNhhWwTm.Ax7smS v6ZzC7JzICjzo5QySTbNdlgAV4SgG8Uz1o0zdjTLgBt5yljyjK8aRt7um1_nInfuvQVnyN6RAaQl CgO9NmZiP8rm.9s294dA0CHk6rW6ETwdVf9xS1HD1thkshIMH4OYFINaK_UdVgibAb.7ErfsM7ry MyD54kGYSaG76emrG41qknaTjjIRrf2G85qtuf7SzxcacfRDn7zZJiZSF_Pl24N_z3jJwYnQAUXP 1IX1EkqxWwJ2GwPgNzRI6mY6mGzNi3tPvcLB8jXXCeoX1.CeCCGns2Y5ZsCcO9PRopZjsm0cGBfP O4x5KNWbR_UUx6XhfiE_F_z3.LZl47OY.HoqoVI_r1wjpfSUu2a5FFllztrhewxeoD91M7rop3al Yf9ub.RYXA8zLfdud21aRIMh0gMbGWi3LDPbXICDns6iy1dpP68U1AH18Ocf8zakm5VzWSB52UAZ SYAdmXeEvoq_dprHNeavScUwzbdfnh_ibW4FXwW9JBhzEW4ivxvHIKr50r4Q0XzaVkRYeDxwiGOV irCrXipK_loz9Yq6No3Uv8lqHxe5H6qqcK7QBMHryDyCCkc42aOU9fUfxAB1GUpIcdjo9Obj7_Ij dCviX2pX0p6y4dOTDjNqq33lC31RZPwz9KR4OBN8vflwOgDfcXM82oZ.wNiR37GComopNOCT0a76 D8x8d7gJoPP1Rz19HgAblcmEUnBDlu3wBWVVUO6bD2d_pDt30e9c9S1iLEIuZ7AFKe6XOly5CqHB eqAbn27N181.cDM4VTzabMK4974TwH3Cif2UJeOG80P7vd_NPn.KTcIaIRsOmHv5TI6nw.VrSBvV sCuQwfZsOOHnllRA3VLiT5_YcrDQkS.Qa81E8Vki6y20XOvPGjLEpB5ovmRob.4kPigGzEzwaZD_ qoY4PnTW_Ipcl7YxhDpomAmA2EKHbCEJGEdkkl6zA5RpOKHR16lHspwj9VsPcReEbSPwxALvnWU5 JXb2z400y.xHdvvTmRgqPetXi8ioznwYEj89tzQpatXHzz8y8RbYt13cN.YxrqjtTkapjKRRmgqC MigkXPu.kO3M6zldVjaZ_qAgUrIlaCf3IM..KY90RBnXItqTrQLJ033srza1xYKQ9ju1YuiX5VVF tVBCZHQNLnS4fSHTk93BK8mZ9rZM8hozfYTiaMRC3SirdAet_rQHBU0J95FcfCaODS0xR7A44I40 A3RtGlPeNoVJZlfaqhagfHl2uPArF1cf0k5zKW_0RZW.J0.JF3JLzY3nSK7Mwn8m2xB4E1YRRme3 KArJnCBmNYrzBVU0osX0RhmvZq5S08VVK_eY0LENxFrZfrFkRSQCAXIP_MJZV8DmjfSBGQw-- X-Sonic-MF: X-Sonic-ID: 79415aee-737c-4a4e-9c25-bea99cb994ed Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 10 Mar 2023 23:52:48 +0000 Received: by hermes--production-sg3-67c57bccff-d5ptt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 68233e667fffdbdd141df7b76be31c58; Fri, 10 Mar 2023 23:52:45 +0000 (UTC) From: Po Lu To: Stefan Monnier Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: (Stefan Monnier's message of "Fri, 10 Mar 2023 13:28:20 -0500") References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> <83v8jgaeqy.fsf@gnu.org> Date: Sat, 11 Mar 2023 07:52:40 +0800 Message-ID: <87h6usf9kn.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21284 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1770 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Eli Zaretskii , mickey@masteringemacs.org, casouri@gmail.com, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >>> I tried cargo-culting the cpu_gc_count stuff for the memory profiler, >>> see the patch below. However, something is amiss: this assertion in >>> profiler.el sometimes triggers: >>> >>> (maphash >>> (lambda (backtrace _count) >>> (let* ((max (1- (length backtrace))) >>> (head (aref backtrace max)) >>> (best-parent nil) >>> (best-match (1+ max)) >>> (parents (gethash head fun-map))) >>> (pcase-dolist (`(,i . ,parent) parents) >>> (when t ;; (<= (- max i) best-match) ;Else, it can't be better. >>> (let ((match max) >>> (imatch i)) >>> (cl-assert (>= match imatch)) <<<<<<<<<<<<<<<<<<<<<<<<<<<< >>> (cl-assert (function-equal (aref backtrace max) >>> (aref parent i))) >>> >>> I cannot reliably reproduce this, and don't understand what causes the >>> assertion. Any hints? >> >> Hmm... I just took a look but can't see neither why your change would >> be more likely to trigger this error than the existing code for the >> `cpu` case, nor why this assertion should always be true. > > I can imagine corner cases where this could trigger, but they all > involve funny business where we change `profiler-max-stack-depth` during > a single profiling run (I think you'd need to write ad-hoc ELisp code > for that). The only other explanation I can see is that we > somehow end up with a backtrace that includes `Automatic_GC` somewhere > not at the top (maybe this can happen with a `post-gc-hook`?). What about gc_in_progress? Why can't we use that? This should avoid everything related to post-gc-hook. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 10 21:42:07 2023 Received: (at 60237) by debbugs.gnu.org; 11 Mar 2023 02:42:07 +0000 Received: from localhost ([127.0.0.1]:56336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1papBP-0005Cd-2Z for submit@debbugs.gnu.org; Fri, 10 Mar 2023 21:42:07 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18271) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1papBN-0005CA-Eu for 60237@debbugs.gnu.org; Fri, 10 Mar 2023 21:42:06 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C614880898; Fri, 10 Mar 2023 21:41:59 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5ABBC80091; Fri, 10 Mar 2023 21:41:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1678502518; bh=39T8y/xuv6mbF0f4DSRpKFpzUrLpev1V52EGtAY+6VI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nXtaP9X/MJG8EGHjzH/Z5Wuvp2hL8ryWrh5RUTB+hDGG7Wr3sZf37Ck5CepTiACDf 3s3cpz34EY8MPBnEpCIdDOGZ5Kod5EU0fnYfApeWCSBzY2bwVt7aethpm3Cz45SjJb rWZuKSpkDpBwGrq9NF2ASvMUnFstMF+QTAHh7Giil/BYmv/yIbeVseoQ1TL0Q+sM33 il71qNZQPe31SEAkH6wk4K6Rm2sZcHNHjET7SpAYrySv19zMfOmNYLS4Ezg7bv8wQ3 jv8b14j7h1u29rBLLqbS2z9XbB1PDazJ5HsgtAcZ0cSvE4j0m6HnMWYkz34u4BaQOG +MkZIEW7vWLvA== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 27888122550; Fri, 10 Mar 2023 21:41:58 -0500 (EST) From: Stefan Monnier To: Po Lu Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <87h6usf9kn.fsf@yahoo.com> (Po Lu's message of "Sat, 11 Mar 2023 07:52:40 +0800") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> <83v8jgaeqy.fsf@gnu.org> <87h6usf9kn.fsf@yahoo.com> Date: Fri, 10 Mar 2023 21:41:57 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.043 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: Eli Zaretskii , mickey@masteringemacs.org, casouri@gmail.com, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I can imagine corner cases where this could trigger, but they all >> involve funny business where we change `profiler-max-stack-depth` during >> a single profiling run (I think you'd need to write ad-hoc ELisp code >> for that). The only other explanation I can see is that we >> somehow end up with a backtrace that includes `Automatic_GC` somewhere >> not at the top (maybe this can happen with a `post-gc-hook`?). > > What about gc_in_progress? Why can't we use that? In the text you quote I simply try and describe the kinds of situations where I think the problem can appear. I don't know which of those are actually possible, nor do I suggest what should be done about it. And yes, maybe we can use `gc_in_progress`. So far I haven't taken a look at that, but feel free to do so. > This should avoid everything related to post-gc-hook. Probably. At the same time, if we're sampling while running `post-gc-hook`, then it's safe to do the "normal" job of the sampling code (the GC proper is completed already), so maybe the better thing to do in that case is to treat it as a backtrace which has `Automatic GC` as its root (i.e. ignore the part of the backtrace that's above `Automatic GC`). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 10 22:30:02 2023 Received: (at 60237) by debbugs.gnu.org; 11 Mar 2023 03:30:02 +0000 Received: from localhost ([127.0.0.1]:56349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1papvl-0006TT-VO for submit@debbugs.gnu.org; Fri, 10 Mar 2023 22:30:02 -0500 Received: from sonic314-22.consmr.mail.ne1.yahoo.com ([66.163.189.148]:42882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1papvj-0006Sy-Sl for 60237@debbugs.gnu.org; Fri, 10 Mar 2023 22:30:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678505392; bh=w0BH3HZfyU/22FN8JhgDngUpCWU6N3XCqT33LstuS4E=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=EdzwWmEnMGIMYOxn4Oaj4kIJz7IQiM64binTojwviKLCdMmKbXdsIZ3S8HGJ97eDXmgO6PClWP7w4NkdWVjrx0W9Z8Zy7B6xCLjuiKnYZJ/mb1gLOPP4mXEP+maaIt8t65MhnXdiVW0r9LpO2kOp/0Vn3LWsx8otw8/SQdhJP7AJox8sX08dmNYWQCGiCJu8oZRt5sfmrOuYq/nUGjEe7bKnMyQU8phQrA2Sow519xNZyvBfF2yXsHNHVvQDah7T41phZxD00x/O4EabiWO1SFDqSYz4VY9eSqXPEgCO9wcUpNrVvkY+BYAzsXMn8lWjc9AG1p8S0rmFfNSPIEI0sA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678505392; bh=F3TnNZqoNFdBm6XGEZ16mX0kPXV2wd3mgzphjfTbo+k=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=G5PNfwHjc0Of32VzocfehdDt4O7jlrS0I5HagAft6zyoIDoFkVqmuXaxOQhldPo67zF8KP6CQvNDhRzQXQx1RQyvbGs3kH8898NK+wAcbVtAWse+JtQ93EAbTBjWiStWK7bgpawA24FAdsEX3t2Lg8j/+x0Za4cw7FYP55rOQ3QktNokhnnR4HERScGO+u4uBdA1gyu3YQvjF7IUQNxdcME3TjZKfPM055n6Umhep87viPpcM9r9To0tDSZOHADxjQZtwiXx0Jw6yGGpkdq5aVb8qEApAQIP1VAfCwON6R8rROvtirNIa5jUkWZnRvkskd+Ckmqo7rZ+5fnAz5LDSQ== X-YMail-OSG: UHmqXhEVM1mHXpH0IJRkTMpgGOK90K2l..LrHjqRsiRX_cHv9humJgAtMk6OuJA p60Vco6aQWjxNawGZsvwr.qnjLnZW4MMNNcsPm3OaLsDeS2iuypA_l6lQUN7rrElhwpZb3Io_dhu U196f_MetRzwyaRwEqCM.RMtNBEd2XmdJE1t2Ve2T5zEQZJLlLUvQgiEGfuOGutAhg8SYcxIEcdY bVitfp35arJ9D3vvuBkipmbA61KM2rxz5kQPUauHdBf05pJ5EUOlUZFJFmc2IPb3fbqLjVLUjjdd PgTc.xv50a6uieELspzNQIZfsi2Ng6TERq6lif_Np0Jxpn_BcMoOSd7d4laWEf9WTAWVj358Niif UG414hqqCjF7m6ixRDShD0bpuZswvDgUyqjKE7a38Yt_H.wuw.WZ.9KwK0TCJa1nTBUU4Kzu61iH PPnrnm2kB3SCkov_KWwR0o9A.n6iQJbD8JHiCdXInl8Aug9XWBBaPbQ5mAkDTm6z4yiykY2MLiX0 .wTszTwDG.iGHTpXOYBsBpgcyttxvjH_b2cHOm87NIRFz1p8FrICSuocwGMg6KpwoHU6OtWQd4_p hHlU0hjQGETF9czMYSE0VeBZL2YubZHzY4T.ly0hs99dlv2qXAxLBY8JfEQgbNzMnjG9VMdi3sw5 CaIbwiGSYnj1phufeam7kYfjlFCGB1PpI9xsonMIIRLyi7ta0HSgb55dJERTDs6NXe_MEWn5XVNr CgwEhsMoIT0e24SyBHT2D7ZhHpt2zqEBdB_h7bLE49oCe7go.8tsHcsTjVO8eelC6Egxe18KJt2F 1pFnDfEBTUWRMMODZram1_IEb97JCAPQoeHRebFxpD0E2u3oj0eB8eOyisWwqJVfFyGwWyhugf3f yK2QMb.hoUk9fr_dxZ6gVFWIDgxYUYv8KzWqBRildy.neumSzjnwAe9DPseHFbHeHWC3XZTWTA7q Q8gVx7odyKZNhPUn45V7iNAcwkYFMKoa3C66CaSsQDa.2HTaldx3TepUkUdz0tksAFr75vLVOMXM 9YD6gydqylePVgrzCqdEOWLeQdMl1Ggpouv7cEk_ySeStMeXuvbS_ku9ieIf5NveeXrP_povZ_IL vpRO5eC1SzppRoGXBFE27jIn.nhDkM.KbmJkzVupgXGlcP4tOlyjXKR2ZD6zlb6365d1.7VWsfov MS_erh4rGntEwW.NK3ymmzJ.TnjZyvwEQmo_eeOorpmW7ushvVfM0.g9lMQoSMRsESlSEKkMf6OL l8G0EUJxVhlAPT_GQQDNHbrD_TltTl8Yiz.HGMDS.P2yEzfZzz.LlApgxHW19kKkf54nuQ5vyKu5 L48u4.aBsIOKThIOsoevKSEtaD17KJdop8Y9WgZbAMtIKcYbE1.pb4QBWNjHVCEtMe.EUUL85cdb MRansHAkU81BONy62pMT5EbIg7CvoVJ75ZMBr2iDnjlnWSDbJuErxPN9z.iXbv4.WYNq_g2oW.SI xmY8fc_nhpFOTDbnPFoXiKcI_jgRsBWiZsmkgYvGP2a6I7tfQ.4OpHXp77EcW0GS6YHsfaoUiCkL Lm9nRrFwUsZwAg1M20XNc90j3E3ZPBfccUbEkiFbfBxeKBcuk3hOJ2HWBz_n1Q1SY0caBZXL9p8h 9pOiLxsezf13CA2vOlWl_rGHwrkZYEtTpBEHDMvPhhhuzMufZittDt8S6Xm2syzdrOq_vj298zAV b7nYXNtJ4Mt_Ije6IlCROV8TM9FNG3HhUbeTgZXGwDegQPMHgVzPxTjO4dLbvTBjsFKmZqsGJcFg aTLgbSRoawXniqQ_GMr_JeJCYqS4KxfxOqWv75GjnZR6uiX6Ou4RAqU.Obfxfc.cAj4KiiZhN2O7 wHps8Pw_4ySCSj7K8OPxVxRAFF0oVyXUuXJlpm._NLWrKiywBSprF79TnihvgcSo8EieXjf8Ev0a 22oPZRBVoO7.MEy6y_kaKAxZYSTWO6yIudCTT_Kgthld_mF9wFi1rDCloOHe1sgX29n.RfdJXJJr Z7vYGJIs_JP9GP2v1f9U3antWeed4L04ROSbIloJe.s_6z419biGbky30oQRY7V2V2vmQQ4WO_PV xZwYvrPx79NLoQ3K_6W1_Hfo_xSPSn3IsK9TVZsg_NeDPQbRlGMyNLVEaioIck4mJiBBi6ky6l35 8L5SIqr005AirnNYOhx8pKkVM7k3.uU1axq_6YlgU.7CuxkkEe4VfYofkhaSBnmoSqGBxlXh7vT8 wxqw7kRlboZCwvHM3neicJAmNHZqg6fsCiuHI9nXjHPLE7MkrXFunNy7eT4MzvVmbAK58ag-- X-Sonic-MF: X-Sonic-ID: 1b4c3cc3-44c5-4613-86ae-6b8e069354d4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Sat, 11 Mar 2023 03:29:52 +0000 Received: by hermes--production-sg3-67c57bccff-wt27l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9ad9813d5654b478b710e19698f37745; Sat, 11 Mar 2023 03:29:49 +0000 (UTC) From: Po Lu To: Stefan Monnier Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: (Stefan Monnier's message of "Fri, 10 Mar 2023 21:41:57 -0500") References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> <83v8jgaeqy.fsf@gnu.org> <87h6usf9kn.fsf@yahoo.com> Date: Sat, 11 Mar 2023 11:29:44 +0800 Message-ID: <87zg8kdkyf.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21284 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 903 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60237 Cc: Eli Zaretskii , mickey@masteringemacs.org, casouri@gmail.com, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > In the text you quote I simply try and describe the kinds of situations > where I think the problem can appear. I don't know which of those are > actually possible, nor do I suggest what should be done about it. > > And yes, maybe we can use `gc_in_progress`. > So far I haven't taken a look at that, but feel free to do so. I thought you'd know a problem or two with `gc_in_progress', which is why you decided to check for QAutomatic_GC in the backtrace. > Probably. At the same time, if we're sampling while running > `post-gc-hook`, then it's safe to do the "normal" job of the sampling > code (the GC proper is completed already), so maybe the better thing to > do in that case is to treat it as a backtrace which has `Automatic GC` > as its root (i.e. ignore the part of the backtrace that's above > `Automatic GC`). That makes sense, yes. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 10 22:38:43 2023 Received: (at 60237) by debbugs.gnu.org; 11 Mar 2023 03:38:43 +0000 Received: from localhost ([127.0.0.1]:56368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paq4B-0006ha-7B for submit@debbugs.gnu.org; Fri, 10 Mar 2023 22:38:43 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55555) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paq49-0006hN-9o for 60237@debbugs.gnu.org; Fri, 10 Mar 2023 22:38:41 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D6879443CC7; Fri, 10 Mar 2023 22:38:35 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8EC16441E97; Fri, 10 Mar 2023 22:38:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1678505914; bh=+znkv4wZe2cdwzYBVCuFamWVrdgE9c+NdVrGEGK95Ao=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=egHLKdDT9IV7uk8/N9PKoX/eivcE+Ib//SL2RIN3jvH0ljr0TIZJGUufqVIMM51qw ZW5X+muM5+IQeDooN2yXRTHBK7TPNJGBvoXhpdf0rwV7Lv7m4l2sdBKNZqlxOow+Uc fl6NOBUTxSp4U33RsFsFuvh/eqZwLDBCysvMG/s8DQCunT7hzKZKH32KRqV+p2eRos ZEpDau7GGUVaocfY6AZaw8BN9iylEi3k5TkroJOKhiqug6AO48qYs1DzELxBBZK21g LXry2vw9a0ebh3FDut8665EZwxkpE5aNFt9E8jTFMQHEjPs++WezQ3jOv/0Vbe7f6X E2ZoiiqbBRc5A== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 47B3C123207; Fri, 10 Mar 2023 22:38:34 -0500 (EST) From: Stefan Monnier To: Po Lu Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <87zg8kdkyf.fsf@yahoo.com> (Po Lu's message of "Sat, 11 Mar 2023 11:29:44 +0800") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> <83v8jgaeqy.fsf@gnu.org> <87h6usf9kn.fsf@yahoo.com> <87zg8kdkyf.fsf@yahoo.com> Date: Fri, 10 Mar 2023 22:38:33 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.090 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: Eli Zaretskii , mickey@masteringemacs.org, casouri@gmail.com, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> In the text you quote I simply try and describe the kinds of situations >> where I think the problem can appear. I don't know which of those are >> actually possible, nor do I suggest what should be done about it. >> And yes, maybe we can use `gc_in_progress`. >> So far I haven't taken a look at that, but feel free to do so. > I thought you'd know a problem or two with `gc_in_progress', which is > why you decided to check for QAutomatic_GC in the backtrace. No. I can't remember why I used `QAutomatic_GC` back when that profiler was first introduced, but I guess it's because I hadn't realized I could use `gc_in_progress`. And now I just preserved the code that was there. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 01:45:46 2023 Received: (at 60237) by debbugs.gnu.org; 11 Mar 2023 06:45:47 +0000 Received: from localhost ([127.0.0.1]:56432 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paszC-0003Hu-J9 for submit@debbugs.gnu.org; Sat, 11 Mar 2023 01:45:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pasz9-0003Hf-Ek for 60237@debbugs.gnu.org; Sat, 11 Mar 2023 01:45:44 -0500 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 1pasz3-0003Cy-S9; Sat, 11 Mar 2023 01:45:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=VIGGc7dmAEMvZyH8GA0xXG4Yao4ToX+x68o3JIu9Wqk=; b=MWHS3ScysutV RWu984bXWBc7mfev9MiWDdMJlcdHFTsXyfPAClSe7BzbRDUhh/E1kPUjgUkS7w50rZ+aY11LVD3w4 ICrKx+uA6EUfPZ99sK82ElcZw6CCd9+WiKymypAA+yaKC+Xew07EM52yhHeL13sWB0WiADVuNSkEW XFF9REV9NVPcJ0Ugr4vEwCvTy5uCWxSxpiTHKI3tx4nTWox0mo1y9R9lqZ09IpOg9kIIQvUOyrkxn vHC5Cn9SaA9qhHMez5E5kPo8TELeLoZs098glYQuXIquvxOTYsGJeNbz8l7NdgiT9ToP/feY7ihfX NnNKy6u/eDUjAVS5povAgw==; 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 1pasz3-0002JH-94; Sat, 11 Mar 2023 01:45:37 -0500 Date: Sat, 11 Mar 2023 08:45:22 +0200 Message-Id: <83r0tvyef1.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Fri, 10 Mar 2023 15:56:56 -0500) Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> <83v8jgaeqy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237 Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: casouri@gmail.com, luangruo@yahoo.com, mickey@masteringemacs.org, > 60237@debbugs.gnu.org > Date: Fri, 10 Mar 2023 15:56:56 -0500 > > I pushed your change to `master`, with my patch on top. Plus a few > other patches to reduce redundancy a bit and fix a FIXME. Thanks. I guess we can now close this issue? From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 12:46:03 2023 Received: (at 60237-done) by debbugs.gnu.org; 11 Mar 2023 17:46:03 +0000 Received: from localhost ([127.0.0.1]:58591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pb3IA-0003VW-UB for submit@debbugs.gnu.org; Sat, 11 Mar 2023 12:46:03 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pb3I9-0003Ul-Em for 60237-done@debbugs.gnu.org; Sat, 11 Mar 2023 12:46:01 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9F50080658; Sat, 11 Mar 2023 12:45:55 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9FE2780058; Sat, 11 Mar 2023 12:45:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1678556753; bh=nVZKSFjymhdkVJmHIaLM5l+46xcnzQ+AEDh7yUtXxIA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Rvp281BL29sttQx0CPM4nf8X9UeuuY0S6horbqyskaZxVqSpTM18ysFa/9ToQA0SO eoO09+o5smslstl8x96UhinRhyDfs9vSF8vHb/bWmr1Ayo4tuXXVDBC2Wu/NqgPl2n j2wlu6zgPbfelQ9X2pSYaWAZJm7eddnt1yqxHuWuqdAnwntWRXkkdic+npOoReQ5TB FujGP3Ni96hBjFWimD4HUTHR47yZ4sXrZQNHBZEuoil5K/VRykVRQFfoouwY3RDz3m 0mIYzhFvc2sA1wH/x0y+FWJuFlre8reAHSdMEJUj0LjLNpxApcLVDWTbIB0dYrfIeA VE/Uq6uXpBcew== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 58DC0123207; Sat, 11 Mar 2023 12:45:53 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node In-Reply-To: <83r0tvyef1.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Mar 2023 08:45:22 +0200") Message-ID: References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> <83v8jgaeqy.fsf@gnu.org> <83r0tvyef1.fsf@gnu.org> Date: Sat, 11 Mar 2023 12:45:51 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.042 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 60237-done Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I pushed your change to `master`, with my patch on top. Plus a few >> other patches to reduce redundancy a bit and fix a FIXME. > Thanks. I guess we can now close this issue? I think so, yes. Stefan From unknown Wed Jun 18 23:13:55 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 09 Apr 2023 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator