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#74547: 31.0.50; igc: assertion failed in buffer.c Date: Sun, 01 Dec 2024 17:55:04 +0200 Message-ID: <86ttbn4cvb.fsf@gnu.org> References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.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="30265"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, oscarfv@telefonica.net, 74547@debbugs.gnu.org, 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 16:56:21 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 1tHmJ3-0007gb-Ou for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Dec 2024 16:56:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHmIm-0001Gi-Jq; Sun, 01 Dec 2024 10:56:04 -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 1tHmIk-0001GU-Ia for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 10:56:02 -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 1tHmIk-0003n7-9z for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 10:56:02 -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=B2VTtmlR9n1W3BwSSa1Cs0Usw2wueJQf4FYzKZDz7xI=; b=WrpDcW/BwuKRo4uVgtVIXtnU4+Wa0xiBEp0PMgsl7/p45uKiHDmV1VsQIy+N+jwy2kY+52te4n2FmD1ffbVtNYtffCbyvz421zEGMRXnxlNyCCwqo8C+AUpfQBRGs5Pfugm6lBtNVLuvtHHxAdCKZC15h7MsZQItq/YKUtE7GmBVSdyzctOGUplk6xxE5cIjwgEd+d2SKg2dobF380nAzfa8+TP+5vQyi2CtwoRETO6E50BGTYzZpMS1nsdYGTWF1R9mu0tMJEPRUVqsq3jtylBOtforAwWNe9qRkxetCN5ArJtWyInULw0RSV8AsvI6kf70N545O5BU24Z5JHhkZg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tHmIk-0000oh-4A for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 10:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Dec 2024 15:56: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.17330685223053 (code B ref 74547); Sun, 01 Dec 2024 15:56:02 +0000 Original-Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 15:55:22 +0000 Original-Received: from localhost ([127.0.0.1]:52716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmI5-0000nA-W5 for submit@debbugs.gnu.org; Sun, 01 Dec 2024 10:55:22 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmI3-0000kB-MT for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 10:55:20 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHmHx-0003by-KO; Sun, 01 Dec 2024 10:55:13 -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=B2VTtmlR9n1W3BwSSa1Cs0Usw2wueJQf4FYzKZDz7xI=; b=nDdfYLdJWXTHdVnxpV70 PQVJqMCEbvz9p4EwbkQG7v7SlJk/rerBMYx9V9wpbTKL4fpyZfxcjafyjssmhnZMx25YeD2hyRbkG WtujS1N3hIUXfASKgZqOD7Ufi74V5ccm9WFQe79dCLrytDwTIJeDTW+SHoAQJ0KefAHckI2xST34R 7C814Z4qk1aYl8jCQ8xKBI3H2ca0GEPbhLqXvCugxPi5nl66nxswFP1mdJxidEFn4u3Vf0yJr1CHs 3mgfCw94tvlX9B0XDBxh38u+6NoXk1vgH+kPwD2cBiM+iGN8da0L41giF2ySSBv9Ix5dnI90SBDaw pJUQ2OdSh1z6sg==; In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Sun, 01 Dec 2024 16:18:31 +0100) 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:296263 Archived-At: > Cc: 74547@debbugs.gnu.org, > Óscar Fuentes , geza.herman@gmail.com > From: Gerd Möllmann > Date: Sun, 01 Dec 2024 16:18:31 +0100 > > Pip Cet writes: > > > Gerd Möllmann writes: > > > >> Pip Cet writes: > > > >>> Gerd Möllmann 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 = (struct json_parser *) parser; > >>>> if (p->object_workspace != 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. */ > >> > >> That explains it, indeed :-(. > > > > Just to be clear, I think the mixed heap/stack allocation is the right > > thing to do here, but we need to let both garbage collectors know about > > the Lisp_Objects we allocated. > > > > I think the best way to do that is to use a Lisp_Vector when we run out > > of stack space. That way, we don't have to worry about forgetting to GC > > it, and we can use standard functions rather than rolling our own. > > Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented > at some point, but removed again, see > > https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/ > > I vaguely remember a longer thread about GC in json.c at the time. Could > be that that was before igc became a realistic possibility, don't > remember. > > And yes, I've forgotten about it, and should actually have fixed this > long ago :-). Please be sure to measure performance. json.c is performance-critical in many applications nowadays, that's why it was implemented in C.