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 15:11:08 +0100 Message-ID: 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: 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="21953"; 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 15:12:22 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 1tURMc-0005WK-EX for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 15:12:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tURML-0002AN-D2; Sun, 05 Jan 2025 09:12: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 1tURMI-00029p-RX for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 09:12: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 1tURMI-0000ii-IQ for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 09:12: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:Date:References:In-Reply-To:From:To:Subject; bh=9Cz4GIa4/uD4ib8Atzsgb1LB4SoegbDCRg+S4xPxd6E=; b=BvT960rS2Q69lPXyteX1zsuI2tGIVVkin3vl87W6qWPbvrqeLlQ5imsXh/DdOgfLzJwILeVSGu/2IwZnF7lFwHr6PYJj+heCgC6G41NXJdOibElc5B1kamz1cenCnSVKi5I4SnA5KilmBP8nfXm68hxzFvjBtsKexGWsUJ0Jed2v1gVUXMUXH4u5FCJqPhcY/MDI+UPvTtRckiS9epEwDyu+KRJzSJiHkCpVdvUk20YogseEKLym5PL1tazP1c3UysH0lmu08xKnbWeaChIq+XXRZ/E9ORty6ueva1Q8LhIwrYIzQF2pTvwyaLF/RK19fScfBEZHZzb3vEuXMmw7wQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tURMI-0005I2-0f for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 09:12: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 14:12:01 +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.173608627620267 (code B ref 75322); Sun, 05 Jan 2025 14:12:01 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 14:11:16 +0000 Original-Received: from localhost ([127.0.0.1]:60430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tURLY-0005Go-Bi for submit@debbugs.gnu.org; Sun, 05 Jan 2025 09:11:16 -0500 Original-Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:61585) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tURLT-0005GW-8v for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 09:11:14 -0500 Original-Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-43675b1155bso126862385e9.2 for <75322@debbugs.gnu.org>; Sun, 05 Jan 2025 06:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736086270; x=1736691070; 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=9Cz4GIa4/uD4ib8Atzsgb1LB4SoegbDCRg+S4xPxd6E=; b=Kiv0ZN4T2haJP/SUsyqQTXc2X1gfJPg+CzUDqsQoap9NfBcDEoXNfiwD+rS1GrZmzS bWLFfABVopwOEyJNBm2d4oezakW80M0//CjAfIcAVMe+wjhe7IxTKI7uz123vZKCa4ah s1WHQb5tD4rt4m9qLairiARn6GyQ9noATw+hKW3YlZ4H0hUezLTA6mMtQ+2ncpIboRc3 dzVFv9rTk6EZNQYkos+u8/Q2ThM3pWPg9+6lVFlwf+bdTXybQoJjh+XUwF76zOiMxqFJ ckbb17H/ABa0u+05cural44onA9xUG0ELsoWrIjCs6+cHzTvSawl9brg6UvJPJCb4Jw7 lg3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736086270; x=1736691070; 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=9Cz4GIa4/uD4ib8Atzsgb1LB4SoegbDCRg+S4xPxd6E=; b=UwSjvyiPMDUAgrAv5Tfs/sKcq5U9LxWVmBxm/sVu2Lb1stO6970xvYvp4DhB3s5eT1 rOwaj1/uwjw3nVmcTUFK5oTf19YEqYR5OyhYu1R3yZHRTucGvw7RixLKfB50PJdqdRW2 qDBwTrsxorIDmvAscwBFwqiH5jygmBbcByEZlCrTHTOPfZ1EkApOTioLGxoWH46RtJqG ToWI4PllPV5Wim5kS8CM8SZ7HnL4RCdgWsKNi6yXufMPd2K0otpQUWynBuLQhE56qYmg pJwSRO+QfZzx2ADfgaocuHV8CwRrYRsoin5xId7Ml14G/UN7qD+Mh61PFqT+wg+4vfpB 7ZJA== X-Forwarded-Encrypted: i=1; AJvYcCVDE7N34c0mIcM7cIGt9eB6wnaJJnM/ZzshGZuwEiBUor1j3/LJJ0RDTVwJsb6TgF7seaG6fA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxu+C8eu6RifrAjGs4G8YvDHZgXWa/byBZJ7iJh8dS5d367MJqn zVIk3ooSQvSw5WbAJhRm7POjX5mBq7QczrHRmetYZD0f7i0leKeXcaN6Qg== X-Gm-Gg: ASbGncs/iIMpvhEhu+iO9uQ47gXPNS61nrAfcIS5/QG6PH10Xjp0lrrn/ZIY1nDykuP jUBi78PBGejYw4nRJoVI8ExPdt2nodFV8Mc1sCXOqgUcPhkEE3fYyQJHKzZjti4vea7krGMPDLi 28ZVQv6wn2qk3Y8n2nDQchFFyRPWrPJaaaqYsn2ngL8dcQBzBmbjmv+m39CP1KIlSMDr92tDYJu ifddx5eFXtXikkiYObquFxGZDHJb9bgisZP3GudjYCIDa7Kwk7JZvlzdQhs7qTXLwPoMXTMUoIR o5xvy0EegOw7jh9kD/8sEhunfeHO6fSfq26uuBUylYJ3/iVzyPNjVS7LYMoDjtTMYNlSbf3BF/f Q8Jnt2wd2 X-Google-Smtp-Source: AGHT+IG0w75GMyO3hC5kaP/QA/bce6l+J5WOY01/WQWmQ3L0s9nqXdTrBCS2aynXBLpMoubaHhP/+A== X-Received: by 2002:a05:600c:19cb:b0:434:f335:849 with SMTP id 5b1f17b1804b1-43668b93637mr450014825e9.29.1736086269532; Sun, 05 Jan 2025 06:11:09 -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-436611ea3d5sm544647825e9.5.2025.01.05.06.11.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 06:11:09 -0800 (PST) In-Reply-To: <8634hx8k1u.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Jan 2025 15:30:37 +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:298565 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org >> Date: Sat, 04 Jan 2025 11:20:41 +0100 >>=20 >> In callproc.c I found two: call_process and create_temp_file both use >> SAFE_NALLOCA to store Lisp_Objects. I think these should be replaces >> with SAVE_ALLOCA_LISP. > > 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. Right. If it doesn't use xmalloc, the references are on the C stack, and both old and new GC handle that by scanning the C stack. > 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=20 Yes. > 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. 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? 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. Or, the other way 'round, by using SAFE_NALLOCA we make an assumption. And that, from my (GCPRO) POV, needs a proof, or better yet some check in code. 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. In the new GC, with MPS, the same is true as above. An object which is only referenced from args2 may die. 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. > > 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? 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. 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. Which was the reason I had to add the mem_blocks, the red-black tree and so on, to be able to determine if some potential pointer can indeed be pointer to cons, conservatively.