From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70059: 30.0.50; c-ts-mode crashes emacs Date: Mon, 08 Apr 2024 14:35:58 +0300 Message-ID: <868r1oytlt.fsf@gnu.org> References: <877chmccux.fsf@web.de> <86edbtfvge.fsf@gnu.org> <87il15wbtx.fsf@web.de> <86zfuhe0uo.fsf@gnu.org> <878r218e1s.fsf@web.de> <86wmpldyve.fsf@gnu.org> <92195FEF-E940-41F7-B1A8-EC1607D9473E@gmail.com> <87a5mex1oi.fsf@web.de> <57C4D40E-15B1-4A8C-8FA7-C01A16A81BA9@gmail.com> <865xwzaa1t.fsf@gnu.org> <08F912D5-CCC4-42C8-8C27-B1CB2085FEA0@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29498"; mail-complaints-to="usenet@ciao.gmane.io" Cc: felix.dick@web.de, 70059@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 08 13:37:13 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rtnJJ-0007T7-7F for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Apr 2024 13:37:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rtnJ2-000720-0K; Mon, 08 Apr 2024 07:36:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rtnJ1-00071s-43 for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 07:36:55 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rtnJ0-00075m-S0 for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 07:36:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rtnJ8-0006NC-5M for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 07:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Apr 2024 11:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70059 X-GNU-PR-Package: emacs Original-Received: via spool by 70059-submit@debbugs.gnu.org id=B70059.171257618224275 (code B ref 70059); Mon, 08 Apr 2024 11:37:02 +0000 Original-Received: (at 70059) by debbugs.gnu.org; 8 Apr 2024 11:36:22 +0000 Original-Received: from localhost ([127.0.0.1]:45414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtnIT-0006JF-1y for submit@debbugs.gnu.org; Mon, 08 Apr 2024 07:36:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtnIN-0006IS-QC for 70059@debbugs.gnu.org; Mon, 08 Apr 2024 07:36:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rtnI9-000721-Jd; Mon, 08 Apr 2024 07:36:02 -0400 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=cIPotBT6Eowkd0P1tmnunfSNiPr+tQZvKGrY23MjrhI=; b=AI5Gl6wQYiMOgM++vzAE RUo2ME9sqth5nQ+npOTCIyFXBm583azcpVu+pHyEDjGpJTc4bsV/he0xC6rpy+37zNaQQp52iP4EJ 1o0Nm4070xIIMxKZeqt/WQ+ocwFWfMyddB1YEk+H7R5Mb/pNPq15LVPiXGWjWaPXySL0aG1/QP224 /HmTqJvM4iWpO4o4MKwlMiqkiNZpXuPFRU1fnrkk1UC/MsGChjbPqfcnK8T0/DDp/DguVZWVp3F2s 4ouA+rKaO9WAADtg/ExECr0gIgHDLaKPo7rSCaI78fsa1ePDBnZTlrNu6rGZQC2bvZL7uJrxoEFlx KGEXEVY2RL7GfQ==; In-Reply-To: <08F912D5-CCC4-42C8-8C27-B1CB2085FEA0@gmail.com> (message from Yuan Fu on Sun, 7 Apr 2024 23:32:01 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282928 Archived-At: > From: Yuan Fu > Date: Sun, 7 Apr 2024 23:32:01 -0700 > Cc: Felix , > 70059@debbugs.gnu.org > > > On Apr 2, 2024, at 11:34 AM, Eli Zaretskii wrote: > > > >> I mean tree-sitter (the library) runs in the main thread, if it triggers a segfault, AFAIK Emacs currently can’t really do anything. Is that right Eli? > > > > You are right. But these crashes seem to be inside GC, which > > processes our objects, so if tree-sitter somehow causes us to create > > invalid Lisp objects, it's our fault, at least to some extent. > > If the crash happens in ts_node_delete, ts_parser_delete or ts_tree_delete, would the backtrace record that? (Given that the tree-sitter library probably isn’g compile with symbols.) If the crash happens in those functions I think it’s not our fault. Even if tree-sitter was not compiled with debug symbols, we'd see the library name in the backtrace. Like here: #14 0x0000723f608fd770 in () at /usr/lib/libc.so.6 #15 0x000062534d063429 in process_mark_stack () #16 0x000062534d1649f1 in traverse_intervals_noorder () #17 0x000062534d063e5e in process_mark_stack () #18 0x000062534d063ceb in process_mark_stack () #19 0x000062534d063ceb in process_mark_stack () #20 0x000062534d064fab in mark_char_table () #21 0x000062534d0650f6 in mark_char_table () As you see, the fact that the crash happened in libc is shown, even though we have no symbols for libc. Looking at the two backtraces posted in this bug, I see that each time the crashes were while processing some char-table. I don't think treesit-related code manipulates char-table's, does it? So I don't think treesit-related code is to blame here, it just so happened that calling treesit-pattern-expand triggered GC; the invalid object was probably created by some unrelated code.