From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74547: 31.0.50; igc: assertion failed in buffer.c Date: Sun, 01 Dec 2024 12:57:04 +0000 Message-ID: <871pyrmui4.fsf@protonmail.com> References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4087"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74547@debbugs.gnu.org, =?UTF-8?Q?=C3=93scar?= Fuentes , geza.herman@gmail.com To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 01 13:58:26 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 1tHjWs-0000qi-0D for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Dec 2024 13:58:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHjWX-0006ec-SS; Sun, 01 Dec 2024 07:58:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHjWV-0006eN-F7 for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 07:58:03 -0500 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 1tHjWU-0002qy-CR for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 07:58:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:From:Date:To:Subject; bh=wA+bbLq4Lfe6Rc3R9EWyYND548P8sKZOKAdjRxqQ7vk=; b=SjeqUPOG6oppO4xdN2m6DyaLmfKedaL9q83pbZPVHk1MTFBJMofDTF0g4qnB37/OXFuEjMp6z2/qKLq/egZbRAtND0Z8qeZq27N25JFfFgF79oPXqzusW7TK5wRMeKyAeMZzLA4YJ7WfIlKQGYLmS3hDkKvH7KaBzFrjAYZ5t57o7B+mDd55tNewVc3OOh9YGRf2tF+Hg7qjaXuj1VxT8JZIkfDwJobZuqP8Dpt2qv6KQGfsBCa19YnSyNoC+ILrQWg1M4oy6pPPJGo7EYOg7VHVqDF9lnTCbs/G1Y7HnLwp5ewC+zwJP8zl0jwyOYH6P4WVds11a+ixbL86sQ4h0w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tHjWU-0007pP-2z for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 07:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Dec 2024 12:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74547 X-GNU-PR-Package: emacs Original-Received: via spool by 74547-submit@debbugs.gnu.org id=B74547.173305783830021 (code B ref 74547); Sun, 01 Dec 2024 12:58:02 +0000 Original-Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 12:57:18 +0000 Original-Received: from localhost ([127.0.0.1]:50662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHjVl-0007o8-1k for submit@debbugs.gnu.org; Sun, 01 Dec 2024 07:57:17 -0500 Original-Received: from mail-10629.protonmail.ch ([79.135.106.29]:22779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHjVi-0007nq-Kb for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 07:57:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733057827; x=1733317027; bh=wA+bbLq4Lfe6Rc3R9EWyYND548P8sKZOKAdjRxqQ7vk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=sikqlcTwDwQ3jG6DKD2JkQZChNdzPFwEIWvmeCtHE0D7S+TK7dhx+UWpSjpklzU4b 5353YnNlgXsPkBwtQbUMsqD5KdD6Z8zthgJ1mU55vt3/rVzpqcr1p22hlF6oqZLsBy 75U3d9K3vThR3vMYfIPp8HyWuaEMNIp3dwSTnUkMPkZVw6dWkHuutocKanINdUqBR/ kk2q0E1vbZ+6aSFG4laSBtT7e8tC7IEPk+jWVcS/ba46hHCpLwQnOAJly+tUEohWYv JtTo1A/9zOp3A6FSe55Lml+V9kXKpqOFCC1F4XfKb+HHGyMENeS9Csy8zaIL33R0Om +54y1QWcsQ/GA== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: bd0ffe0075a04b40a1874584e6a393fa70e5ad96 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:296247 Archived-At: Gerd M=C3=B6llmann writes: > Pip Cet writes: > Yes, exactly, json.c. First thing I saw when searching for xfree > > static void > json_parser_done (void *parser) > { > struct json_parser *p =3D (struct json_parser *) parser; > if (p->object_workspace !=3D p->internal_object_workspace) > xfree (p->object_workspace); > > That at least needs an explanation. I would have expected it to be > allocated as root. Well, the explanation is this comment: /* Lisp_Objects are collected in this area during object/array parsing. To avoid allocations, initially internal_object_workspace is used. If it runs out of space then we switch to allocated space. Important note: with this design, GC must not run during JSON parsing, otherwise Lisp_Objects in the workspace may get incorrectly collected. */ Obviously, we cannot make any such guarantees when MPS is in use. (I don't think we can make the guarantee when MPS is not in use, but I'm not totally certain; we certainly allocate strings while parsing JSON, which is sufficient to trigger GC in the MPS case). Note that the json_parser object itself is fine (it's allocated on the stack, thus marked ambiguously), it's only in the case that we create more than 64 Lisp_Object values when parsing a single JSON document that we end up with untraced references on the heap. I don't know whether it's likely that that was what happened to Oscar. My gut feeling is 64 objects would be easily reached by LSP messages, but I'd need more time to test. Anyway, here's a patch which might help: commit c175744f2172ba3405ae98eb3575b2bf4adadfa4 Author: Pip Cet Date: Sun Dec 1 12:46:08 2024 +0000 Ensure JSON parser allocations are traced (bug#74547) =20 * src/json.c (json_parser_done): (json_make_object_workspace_for_slow_path): Use IGC-aware allocations. diff --git a/src/json.c b/src/json.c index eb446f5c221..900fbcbb41a 100644 --- a/src/json.c +++ b/src/json.c @@ -807,7 +807,11 @@ json_parser_done (void *parser) { struct json_parser *p =3D (struct json_parser *) parser; if (p->object_workspace !=3D p->internal_object_workspace) +#ifdef HAVE_MPS + igc_xfree (p->object_workspace); +#else xfree (p->object_workspace); +#endif if (p->byte_workspace !=3D p->internal_byte_workspace) xfree (p->byte_workspace); } @@ -833,17 +837,31 @@ json_make_object_workspace_for_slow_path (struct json= _parser *parser, if (parser->object_workspace_size =3D=3D JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE) { +#ifndef HAVE_MPS new_workspace_ptr =09=3D xnmalloc (new_workspace_size, sizeof (Lisp_Object)); +#else + new_workspace_ptr +=09=3D igc_xalloc_lisp_objs_exact (new_workspace_size); +#endif memcpy (new_workspace_ptr, parser->object_workspace, =09 (sizeof (Lisp_Object) =09 * parser->object_workspace_current)); } else { +#ifndef HAVE_MPS new_workspace_ptr =09=3D xnrealloc (parser->object_workspace, new_workspace_size, =09=09 sizeof (Lisp_Object)); +#else + new_workspace_ptr +=09=3D igc_xalloc_lisp_objs_exact (new_workspace_size); + memcpy (new_workspace_ptr, parser->object_workspace, +=09 (sizeof (Lisp_Object) +=09 * parser->object_workspace_current)); + igc_xfree (parser->object_workspace); +#endif } =20 parser->object_workspace =3D new_workspace_ptr;