From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sun, 05 Jan 2025 19:17:37 +0100 Message-ID: References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> <86ed1jf1tp.fsf@gnu.org> <865xmugawr.fsf@gnu.org> <8634hx8k1u.fsf@gnu.org> <86msg56to8.fsf@gnu.org> 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="2388"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 05 19:18:15 2025 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 1tUVCZ-0000WG-52 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 19:18:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUVCU-0003NL-7h; Sun, 05 Jan 2025 13:18:10 -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 1tUVCO-0003Jc-26 for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 13:18:05 -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 1tUVCM-0003Zf-Az for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 13:18: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:Date:References:In-Reply-To:From:To:Subject; bh=sKwICosqQGUWMOSULo+wXkpI9RhyQUSNyvGxhC6LwMw=; b=trMkotD6thmeVPekgvY4ZEzv4DMq6WhqUokvxXlaEDz5p4YTvPk0LqW0BpzWE2GfzZ1rrlKdwFfZ/Mh89h+yTFbIKeTSV1epZJ5adMDEcl96IX9qmTz3M42NxYJ9iaVxAyAvPeF+r6QQZ15//cYoon2i+KyLGmtu8KMTi7gBI96yjo7kacm6+J8i5ZxfzmIkspb64X4SsvHqVr+afiaX5F26+XdvE9awNgBx76G3G1azVlOSksFmKy2FFhmGcU0ZV7ZxfpHPEmayjUtGMsbjvGljOVBg1edlA1PpWgczOj9EguiTsG/TA8asZd/xJKPfD0qPn9dO3Jg1tEkR985W7w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUVCM-00017w-5C for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 13:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2025 18:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75322 X-GNU-PR-Package: emacs Original-Received: via spool by 75322-submit@debbugs.gnu.org id=B75322.17361010654292 (code B ref 75322); Sun, 05 Jan 2025 18:18:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 18:17:45 +0000 Original-Received: from localhost ([127.0.0.1]:35134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUVC5-000179-1l for submit@debbugs.gnu.org; Sun, 05 Jan 2025 13:17:45 -0500 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:43487) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tUVC1-00016v-QZ for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 13:17:43 -0500 Original-Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-43626213fffso85321285e9.1 for <75322@debbugs.gnu.org>; Sun, 05 Jan 2025 10:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736101059; x=1736705859; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=sKwICosqQGUWMOSULo+wXkpI9RhyQUSNyvGxhC6LwMw=; b=mOj5g1BnZOef1KugVd4hdN5GBM6OKF99i272wRQ+sO45bkPduWO1nEf9IxHZVu0O0V 6meF6rPvGTOa+rs0xpHtznMusawWqdyzasOw1ejWPMzAr+gBVR/LHDBKJo4qn6sOqks2 h0pRbqVpeuuHdk4dy3XAbsFp3a4JDNYZsJj4tTygSuxtgg1gdj5qh+NfQ3SOPf0qK1DF rcS6bdLd81pqHOBLSYYr+dgSANyjbm+r7oUh56p/bBcnp9RREwtMxa+beujjL9iU4Z4r Wt3y0yzyVGa8VpSjC8N0b9m6Ve5R+FViupLJmklWnmA4LtlGLMetrDrYqlnIovziaJey M4kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736101059; x=1736705859; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=sKwICosqQGUWMOSULo+wXkpI9RhyQUSNyvGxhC6LwMw=; b=AzaWYr0Hxyhi2c/N5arxYa0BKJtAGanegF5QU1QNywYWDBpQXzngm9NLifmT97bMHC BQjxxwDMlT1Z4Qhv8dmoQK75VsdkTrcJaMFd7PXJVKMYLv9dAVeh939KZrFjkRXhHb44 1RiI0SDEvaKbskeHnZHy6Jna2GB9hakpHBed5UqZ00ji3jZoNZ3kSAysoonKWoa86JAS ICv03hTfAA8JCvXciQByWFNZQSB95frfokRFZOCOK34igk4wfYbKsme+tEsJyKPoz5HQ n8YCbnfPI/Hp3hTlWv3f/NAtiGwUWHSNPtldhGpe2tBLoK6kP6sRolEJQTGCPp/XMI9j LwQw== X-Forwarded-Encrypted: i=1; AJvYcCUCIS3sq0XDs+ygLGGqbCUeB+0e9NpowoW+0wHg2OUshWOtjcJWd7HjfOx31sy5VJ6QNuwfBQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxBS3wyaQ6jqtPbBJU/iz/emQLLuNYcWyZGjzqvF1glupILD5Jl tOpUmE+qnl0OusJIg6gds3SIF/UTcgZZbJ5aeqWSz7BNDEqI5LvGYk3uUw== X-Gm-Gg: ASbGnctXmollH1NZ2ISzi9BI/JKlRjCkpa6KgSEF+yoVvcPduKDVL8WZNRc6dMW/ED8 T9WPwNOtYh/yvL+WWEvGjbS6KK7oWJGyzJahdHo/cFIJ9l1B6LNSoZ9X/FeCHDhAeP6AXx872U1 Z7Lk+Dk8zCWBI+/8jwRYxiGkbyG6OGZnShnHxFyD+DFvA4yg8Uh8qEan/vY+Nd923lxpFdcGX7/ 5y4Xul/+DIMCj1IWQkqUrmSPF59UBXtd73YtXDrAQpXdmK2Lu0bQzxvPXmTpBPfRdCZ5DGP8eRs p7rT1jjYCK49GWHgvXmRscNJptx7Ph6D1ptAX+8BbrH8PkjfuNMwHtAkDY4hLS2D+g== X-Google-Smtp-Source: AGHT+IFiqMVLi/vAwBmzMRHwktImKEUuiLWluZMKFRe0go5+dZUwIcGf1Wuea0IjbzPFkgctMDzs7w== X-Received: by 2002:a05:600c:a0a:b0:434:9e17:190c with SMTP id 5b1f17b1804b1-436693f7cc4mr438177825e9.0.1736101059405; Sun, 05 Jan 2025 10:17:39 -0800 (PST) Original-Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43661200abesm542439945e9.18.2025.01.05.10.17.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 10:17:39 -0800 (PST) In-Reply-To: <86msg56to8.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Jan 2025 19:45:43 +0200") 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:298583 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org >> Date: Sun, 05 Jan 2025 15:11:08 +0100 >>=20 >> Eli Zaretskii writes: >>=20 >> > And if GC _can_ happen, >> > but we don't use the allocated block again, is that a problem? For >> > example, in this fragment: >> > >> > SAFE_NALLOCA (args2, 1, nargs + 1); >> > args2[0] =3D Qcall_process; >> > for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i]; >> > coding_systems =3D Ffind_operation_coding_system (nargs + 1, args= 2); >> > val =3D CONSP (coding_systems) ? XCDR (coding_systems) : Qnil; >> > >> > Let's say Ffind_operation_coding_system could trigger GC. But we >> > never again use the args2[] array after Ffind_operation_coding_system >> > returns. Is the above still unsafe? If so, could you tell what >> > could MPS do during GC to make this unsafe? >>=20 >> Let me first say why I find this unsafe in the old GC, in principle. If >> we don't assume anything about the objects referenced from args2, then a >> reference in args2 may well be the only one to some object. In this >> case, the old GC would sweep it. > > OK, but in most, if not all of these cases, the objects are referenced > from the stack. For example, in the above fragment, the args[] array > is on the stack. Right? That args is a parameter call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, So just from this I see only args itself on the stack, not args[0], args[1] and so on. I would have to look at all callers to determine that. Not good enough in my book. > >> Not using arg2 after Ffind_operation_coding_system above is not enough. >> It would have to be not using args2 after the GC has run. Maybe that's >> _in_ Ffind_operation_coding_system. > > OK, agreed. > >> Additionally, objects might not die but may move, assuming that >> SAFE_NALLOCA does not create an ambiguous root. So, using SAFE_NALLOCA >> makes another assumption in the MPS case: that something else prevents >> the objects from moving. Another proof or check required with my GCPRO >> hat on. > > What does it mean in detail "the object may move"? A Lisp object is a > tagged pointer. Do you mean the pointer should no point to a > different address, i.e. the value of a Lisp object as a number should > change to still be valid?=20=20 Exactly. Unless an ambiguous reference prevents the copying that can happen. > And if so, is MPS supposed to find all the copies of that value > everywhere in order to update them? So if I have several variables > which were all assigned a value of the same Lisp object, they all need > to be updated when the object moves? Yes. MPS does that with the help of our dflt_scan and its subroutines where we call MPS_FIX2 and update the reference. >> > Also, in some other message you said SAFE_NALLOCA is unsafe if >> > _pointers_ to Lisp objects are placed in the memory SAFE_NALLOCA >> > allocates off the heap. In call_process I see that we only ever put >> > Lisp objects into the memory allocated by SAFE_NALLOCA. If that is >> > unsafe, could you tell what MPS does during GC which makes this >> > unsafe? >>=20 >> Not sure, is the question why in MPS both pointers and Lisp_Object count >> as "references"? > > Yes, if that's the situation. Earlier you only mentioned pointers to > Lisp objects, something that happens relatively rarely. That's the case in MPS. Fixnums aside, Lisp_Object is basically also only a pointer, with some tag bits added. In that sense it's the same case. And every string contains a pointer to it's data, which I consider part of the Lisp data. And intervals are also Lisp data. The ones from enum igc_obj_type.