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: Mon, 06 Jan 2025 10:27:26 -0500 Message-ID: <489E3C1A-0423-4902-9805-6565C3DECE8F@dancol.org> 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> <86h66d6pw1.fsf@gnu.org> <4B76EB57-AA29-40BC-8361-0906E00A3578@dancol.org> <867c786quc.fsf@gnu.org> <87wmf8t2vq.fsf@dancol.org> <86h66c562y.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="19661"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android Cc: gerd.moellmann@gmail.com, 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 Mon Jan 06 16:28:19 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 1tUp1e-0004sp-Mh for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Jan 2025 16:28:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUp1Q-0004Pz-TD; Mon, 06 Jan 2025 10:28:05 -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 1tUp1O-0004PY-Qz for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 10:28: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 1tUp1O-0005E5-E1 for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 10:28: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=lXZWwtcIDDCmRMVbGWNO8L52cmgNjQRQ0zPut/0W/04=; b=KFFT2WW8E1FzRPAIfXOMppLK5cMWStaywacNx+XUGYs0KaYxtLmXQ0/yfR309smNVTJgTlkt9Qx1uzB0KVtjFjUPLoTFWBcLjLmn1QcTl9HguYx2rOub4qwR+hZUsY2e9vTHIAKONB+30QhfURtBOVSwngQUjSkKxx6dl4nqYtxy4iFYWbjG5skhqiz4Z7woBYIJNhe8tTKqs5iuPyGBmnc3VU/f3az/bbo7a6ESN65PKGO0JbgvrsIJ5bANXGTEPfi3m9RjmqnkmOp4aVNOa57WG29hcllaUfozyPDqkqens8O4uQpQ1A808UQBbL/zh1e8IWGSU5UOZYMOfbPxhA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUp1O-0002Wo-7J for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 10:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2025 15:28: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.17361772599669 (code B ref 75322); Mon, 06 Jan 2025 15:28:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 15:27:39 +0000 Original-Received: from localhost ([127.0.0.1]:39698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUp10-0002Vp-MZ for submit@debbugs.gnu.org; Mon, 06 Jan 2025 10:27:39 -0500 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:40454) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUp0x-0002Vc-JK for 75322@debbugs.gnu.org; Mon, 06 Jan 2025 10:27:37 -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=lXZWwtcIDDCmRMVbGWNO8L52cmgNjQRQ0zPut/0W/04=; b=Z6KnYWDo8t7uQKvx0ZH3i9KVlX F5ezPmZNo1uHBDp8Y/RxTfJ1feUsXRBvvaKC+uJtAyG9RWMpomVs83Epb6cRy62RobN6SILaxuB6M pzcIrjFEc4tBBvI8r5djmsc78bwLLUEzvMibl73ay9JCmKOi9liaLRHNdOaUoHhk0yk5NROqrGg2y e6FK5yxFctJs46OPKqsD5UGeApXua2a/FAfN0FWFbHNH1w+faDpgTKNqyYqtCnT/29nnFEMqKEKMt qmc2SNRvV1wBD5BAsUjpvJUMDMJnhFFr55ZIQSWXBsbOI2FkaVOTNlB1hQ/3HfSL1HmkGFUnh7lpv 19UG3Dxg==; Original-Received: from [2600:1006:b124:d0da:0:51:7436:4301] (port=55208 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 1tUp0q-0002h8-1i; Mon, 06 Jan 2025 10:27:28 -0500 In-Reply-To: <86h66c562y.fsf@gnu.org> 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:298675 Archived-At: On January 6, 2025 10:12:53 AM EST, Eli Zaretskii wrote: >> From: Daniel Colascione >> Cc: gerd=2Emoellmann@gmail=2Ecom, pipcet@protonmail=2Ecom, 75322@debb= ugs=2Egnu=2Eorg >> Date: Mon, 06 Jan 2025 09:48:09 -0500 >>=20 >> I wouldn't call it a "rewrite"=2E If auditing the codebase for memory >> safety is a "rewrite", I'm a "duck"=2E We're talking about a few hundr= ed >> lines of changes at the most=2E Most of the work is just auditing the >> code for problems=2E We should be grateful Gerd has done this work >> already, not "run away from MPS, fast"=2E > >I _am_ grateful to Gerd (and Helmut, and Pip, and others who work on >this)=2E I also invested a significant, albeit smaller, effort on my >part into this branch=2E However, the potential amount of changes still >bothers me=2E I understand it doesn't bother you, so I guess we >disagree in our estimations=2E > >> > 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, arg= s2); >> > val =3D CONSP (coding_systems) ? XCDR (coding_systems) : Qnil; >> > >> > "Look, ma: no pointers!" >>=20 >> Lisp_Object val, *args2; >>=20 >> In the C programming language, "*" means "pointer"=2E > >Are we going to argue about pointers and arrays? > >> > So this code needs to be changed=2E >>=20 >> The snippet you quoted above can be fixed with a one-liner --- replace >> SAFE_NALLOCA with SAFE_ALLOCA_LISP=2E > >It's just one example, and there are many like it=2E So that one-liner >is multiplied many times=2E > >And then we have variations, where args[] gets text of strings or some >other similar stuff=2E Etc=2E etc=2E > >> > And if you look around, we have quite a lot of these in many places= =2E >>=20 >> Sounds like Gerd's spent some time hunting them down=2E > >Sure, but I'm afraid there are many more=2E > >> > We have almost 200 static >> > Lisp_Object variables, probably not all of them staticpro'd (8 of the= m >> > inside functions, like the above example, so definitely not >> > staticpro'd)=2E So now we need to examine the uses of all of them an= d >> > either staticpro them or do something else (like move the assignment >> > to 'last_coding' to after call_some_function)=2E >>=20 >> Changing eight variables from function statics to file statics hardly >> seems like a monumental effort=2E > >After you found them, and after you know they should be changed, yes=2E >It's easy to account for the knowns; the problem is always the >unknowns=2E That's why most effort estimations are inaccurate=2E I >wonder what are our unknowns here, and how many of them are there=2E I'm a lot less worried than you are about the unknown unknowns=2E I have a= few specific reasons why: 1) we caught most of the movement-unsafe global references when we did pdu= mper, which, like MPS, moves things around in memory and so has to worry ab= out the kind of unsafe references we're discussing here=2E 2) when I did my own moving GC a few years ago, I didn't run into serious = problems with movement-unsafe references, although, like Gerd and others ha= ve done on the MPS branch, I had to fix a few 3) it should be possible (I don't know whether MPC implements this or not,= but it could) to arrange for a debugging mode moving GC that moves *everyt= hing* not pinned from the from-space to a non-overlapping to-space, then ap= plies PROT_NONE to any part of the from-space not used for a pinned object= =2E This way, any GC-invisible Lisp_Obiects (or other pointers) "left behin= d" because we forgot to tell the GC about them will produce an immediate SI= GSEGV when used=2E We could even conservatively scan for them=2E=20 #3 is probably overkill, but it's something we could try if we attempted t= o merge MPS and found chronic problems=20 >> The static-storage global-scope >> Lisp_Object variables are probably almost all gcproed already=2E > >Maybe=2E But someone needs to verify that, right? A few people have already done things like this over the years=2E