From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sun, 05 Jan 2025 16:01:00 -0500 Message-ID: <225431A0-98C1-4F95-B290-AB86F5379030@dancol.org> References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> <86ed1jf1tp.fsf@gnu.org> <865xmugawr.fsf@gnu.org> <8634hx8k1u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----EN20G1X4PPGH1HCPMNGOMU7GD3X3W0 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1116"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android Cc: pipcet@protonmail.com To: 75322@debbugs.gnu.org, gerd.moellmann@gmail.com, eliz@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 05 22:02:42 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 1tUXlh-00008e-Fw for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 22:02:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUXlF-00088L-49; Sun, 05 Jan 2025 16:02:13 -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 1tUXl6-00087u-Nz for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 16:02:07 -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 1tUXl5-0002UN-7u for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 16:02:04 -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=m5NHn3Q8s2jgMoBinmO9HnIBkb4UM3ZHvpuYkKiAxvU=; b=catG60X9IRmBOD2TYLoilwS43O6srZuhzQcaedtgrGoTbPizltEKQ0R1z2G31LovIMpuQLM3mDMHssKb+3nRH/O5+OInbWVWNPUpRfaHKHLZlsg8hFBXqWuKMmf17h/IWuHlyvvgcIqzC6FyX3/KB8fe05Kdy+8FC8QD/TtKB1FjwbwpsLVod4JSE0zoj5IDGWkut7H/oNeMp9KFipwp96JsiHFpdElwroIq+sIR3aWKbBNx0aLHDMWd1xrwhp+dzamMFIAnPJk8BpTPy/zNJ8999WhwD13k+lGpZGuGDrHhJkveoQTsVVH19yhHWVD1cGWeE1wc30mlpd1/1jMeow==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUXl5-0001ra-2a for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 16:02:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2025 21:02:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75322 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org, Gerd =?UTF-8?Q?M=C3=B6llmann?= , Eli Zaretskii X-Debbugs-Original-Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org Original-Received: via spool by 75322-submit@debbugs.gnu.org id=B75322.17361108797071 (code B ref 75322); Sun, 05 Jan 2025 21:02:03 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 21:01:19 +0000 Original-Received: from localhost ([127.0.0.1]:35475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUXkN-0001px-0P for submit@debbugs.gnu.org; Sun, 05 Jan 2025 16:01:19 -0500 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:36844) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUXkF-0001pf-8n for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 16:01:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=m5NHn3Q8s2jgMoBinmO9HnIBkb4UM3ZHvpuYkKiAxvU=; b=oXPoWoyRUGv/E8YJ9QMSqCac99 oraDlWkgHbmOMT6SKAoazsqjXns9Lyi9bRMyqGsK2Vt9sUMUyO424t/gfMEZtQVLE5YFZ8CdSM9DL iBTsxHGG6yZ/6KtS18uk7E/hz3VJuKqg7N32zbjg0mcnxxUrmWRyeQY7TofXh4VzSNstTH9cdKPz7 +RUIbgrALQQhY+CgBx8FiFuzqwa8CVujdBOgH1ZC3SbSx2MrLnxxmyE48Dq5SlnllTLfXrrd1E6rZ THjeTWDYp4jFO6Fkb1nY4Ms+QVs4OvLs+V7/S9TqE9RgGRcBAq3f6J3tzO3FKwR05JUzxMfw2vpri 81m6CDVQ==; Original-Received: from 2603-9001-4203-1ab2-9d33-bea9-4999-a2af.inf6.spectrum.com ([2603:9001:4203:1ab2:9d33:bea9:4999:a2af]:60724 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tUXk3-00064v-2f; Sun, 05 Jan 2025 16:01:00 -0500 In-Reply-To: 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:298610 Archived-At: ------EN20G1X4PPGH1HCPMNGOMU7GD3X3W0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On January 5, 2025 9:11:08 AM EST, "Gerd M=C3=B6llmann" wrote: >Eli Zaretskii writes: > >>> From: Gerd M=C3=B6llmann >>> Cc: pipcet@protonmail=2Ecom, 75322@debbugs=2Egnu=2Eorg >>> Date: Sat, 04 Jan 2025 11:20:41 +0100 >>>=20 >>> In callproc=2Ec I found two: call_process and create_temp_file both us= e >>> SAFE_NALLOCA to store Lisp_Objects=2E I think these should be replaces >>> with SAVE_ALLOCA_LISP=2E >> >> What are the conditions under which placing Lisp objects into >> SAFE_NALLOCA is not safe? >> >> I understand that the first condition is that SAFE_NALLOCA uses >> xmalloc instead of alloca=2E > >Right=2E If it doesn't use xmalloc, the references are on the C stack, an= d >both old and new GC handle that by scanning the C stack=2E > >> But what are the other conditions? Is one of them that GC could >> happen while these Lisp objects are in the memory allocated by >> SAFE_NALLOCA off the heap? =20 > >Yes=2E > >> IOW, if no GC happen, is that still unsafe? 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, args2= ); >> val =3D CONSP (coding_systems) ? XCDR (coding_systems) : Qnil; >> >> Let's say Ffind_operation_coding_system could trigger GC=2E But we >> never again use the args2[] array after Ffind_operation_coding_system >> returns=2E Is the above still unsafe? If so, could you tell what >> could MPS do during GC to make this unsafe? > >Let me first say why I find this unsafe in the old GC, in principle=2E 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=2E In this >case, the old GC would sweep it=2E Gerd is right=2E This pattern was never safe=2E > Or, the other way 'round, by using >SAFE_NALLOCA we make an assumption=2E And that, from my (GCPRO) POV, need= s >a proof, or better yet some check in code=2E > >Not using arg2 after Ffind_operation_coding_system above is not enough=2E >It would have to be not using args2 after the GC has run=2E Maybe that's >_in_ Ffind_operation_coding_system=2E > >In the new GC, with MPS, the same is true as above=2E An object which is >only referenced from args2 may die=2E Right, because the backing storage for args2 might be in the mallloc heap,= and GC doesn't scan the mallloc heap=2E >Additionally, objects might not die but may move, assuming that >SAFE_NALLOCA does not create an ambiguous root=2E So, using SAFE_NALLOCA >makes another assumption in the MPS case: that something else prevents >the objects from moving=2E Another proof or check required with my GCPRO >hat on=2E Yes=2E In any system, a reference the GC doesn't know about must be assume= d to be garbage the instant it's created=2E Every object is dead unless the= GC can prove it's alive=2E >> 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=2E In call_process I see that we only ever put >> Lisp objects into the memory allocated by SAFE_NALLOCA=2E If that is >> unsafe, could you tell what MPS does during GC which makes this >> unsafe? > >Not sure, is the question why in MPS both pointers and Lisp_Object count >as "references"? > >If it's that, it's basically the same in the old GC=2E For example, when >marking the C stack, we must recognize both pointers to Lisp_Cons and >Lisp_Objects that look like conses, which contain such a pointer=2E=20 And a third case: interior pointers=2E A native pointer to a Lisp object i= sn't necessarily pointing to the start of that object=2E ------EN20G1X4PPGH1HCPMNGOMU7GD3X3W0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On January 5, 2025 9:11:08 AM = EST, "Gerd M=C3=B6llmann" <gerd=2Emoellmann@gmail=2Ecom> wrote:
&g= t;Eli Zaretskii <eliz@gnu=2Eorg> writes:
>
>>> From= : Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom>
>>> C= c: pipcet@protonmail=2Ecom,=C2=A0 75322@debbugs=2Egnu=2Eorg
>>>= Date: Sat, 04 Jan 2025 11:20:41 +0100
>>>
>>> In = callproc=2Ec I found two: call_process and create_temp_file both use
>= ;>> SAFE_NALLOCA to store Lisp_Objects=2E I think these should be rep= laces
>>> with SAVE_ALLOCA_LISP=2E
>>
>> What= are the conditions under which placing Lisp objects into
>> SAFE_= NALLOCA is not safe?
>>
>> I understand that the first co= ndition is that SAFE_NALLOCA uses
>> xmalloc instead of alloca=2E<= br>>
>Right=2E If it doesn't use xmalloc, the references are on th= e C stack, and
>both old and new GC handle that by scanning the C sta= ck=2E
>
>> But what are the other conditions?=C2=A0 Is one o= f them that GC could
>> happen while these Lisp objects are in the= memory allocated by
>> SAFE_NALLOCA off the heap?=C2=A0
><= br>>Yes=2E
>
>> IOW, if no GC happen, is that still unsaf= e? And if GC _can_ happen,
>> but we don't use the allocated block= again, is that a problem? For
>> example, in this fragment:
&g= t;>
>> =C2=A0=C2=A0=C2=A0 SAFE_NALLOCA (args2, 1, nargs + 1);<= br>>> =C2=A0=C2=A0=C2=A0 args2[0] =3D Qcall_process;
>> = =C2=A0=C2=A0=C2=A0 for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i= ];
>> =C2=A0=C2=A0=C2=A0 coding_systems =3D Ffind_operation_codin= g_system (nargs + 1, args2);
>> =C2=A0=C2=A0=C2=A0 val =3D CONSP = (coding_systems) ? XCDR (coding_systems) : Qnil;
>>
>> Le= t's say Ffind_operation_coding_system could trigger GC=2E=C2=A0 But we
&= gt;> never again use the args2[] array after Ffind_operation_coding_syst= em
>> returns=2E=C2=A0 Is the above still unsafe?=C2=A0 If so, cou= ld you tell what
>> could MPS do during GC to make this unsafe?>
>Let me first say why I find this unsafe in the old GC, in prin= ciple=2E If
>we don't assume anything about the objects referenced fr= om args2, then a
>reference in args2 may well be the only one to some= object=2E In this
>case, the old GC would sweep it=2E

Gerd is= right=2E This pattern was never safe=2E

> Or, the other way 'rou= nd, by using
>SAFE_NALLOCA we make an assumption=2E And that, from my= (GCPRO) POV, needs
>a proof, or better yet some check in code=2E
= >
>Not using arg2 after Ffind_operation_coding_system above is not= enough=2E
>It would have to be not using args2 after the GC has run= =2E Maybe that's
>_in_ Ffind_operation_coding_system=2E
>
&g= t;In the new GC, with MPS, the same is true as above=2E An object which is<= br>>only referenced from args2 may die=2E

Right, because the back= ing storage for args2 might be in the mallloc heap, and GC doesn't scan the= mallloc heap=2E

>Additionally, objects might not die but may mov= e, assuming that
>SAFE_NALLOCA does not create an ambiguous root=2E S= o, using SAFE_NALLOCA
>makes another assumption in the MPS case: that= something else prevents
>the objects from moving=2E Another proof or= check required with my GCPRO
>hat on=2E

Yes=2E In any system,= a reference the GC doesn't know about must be assumed to be garbage the in= stant it's created=2E Every object is dead unless the GC can prove it's ali= ve=2E

>> Also, in some other message you said SAFE_NALLOCA is = unsafe if
>> _pointers_ to Lisp objects are placed in the memory S= AFE_NALLOCA
>> allocates off the heap=2E=C2=A0 In call_process I s= ee that we only ever put
>> Lisp objects into the memory allocated= by SAFE_NALLOCA=2E=C2=A0 If that is
>> unsafe, could you tell wha= t MPS does during GC which makes this
>> unsafe?
>
>No= t sure, is the question why in MPS both pointers and Lisp_Object count
&= gt;as "references"?
>
>If it's that, it's basically the same in= the old GC=2E For example, when
>marking the C stack, we must recogn= ize both pointers to Lisp_Cons and
>Lisp_Objects that look like conse= s, which contain such a pointer=2E

And a third case: interior point= ers=2E A native pointer to a Lisp object isn't necessarily pointing to the = start of that object=2E
------EN20G1X4PPGH1HCPMNGOMU7GD3X3W0--