From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 48A711F4BE for ; Mon, 21 Oct 2024 09:10:09 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=ob+TML6+; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=FYs1Bs9Z; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1729501802; bh=/l9ISzoMinajJOF5E8BDPwpxlb8Y//7Eqeib6OgT7Z4=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=ob+TML6+A6P9LOA/yYgLNEdMY4s97oYeEP0qDFOf5rbRVHeWgyTRi3ea4uLmpGYA1 RJqAbkJDcnvVcbvjlcpTGuqER2N2/MdzTFBD+qoyiS15y8Rb/fwLNcMQXM2sFc0ri0 L9R4t1j7gtNkMm5Fea7itcZJ6u7n1VpXf55kbht8= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 50DFA466A8 for ; Mon, 21 Oct 2024 09:10:02 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=FYs1Bs9Z; dkim-atps=neutral Received: from s.wrqvtvvn.outbound-mail.sendgrid.net (s.wrqvtvvn.outbound-mail.sendgrid.net [149.72.120.130]) by nue.mailmanlists.eu (Postfix) with ESMTPS id C6F834453D for ; Mon, 21 Oct 2024 08:50:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=6EUUv9efooCZCM2qJtcPbgajZUoFremgsNizk+3Dp6w=; b=FYs1Bs9Z53z6sKJv55vE4BroNTGbMtlcz9IoIFaI5j+0wUF89iHCUPkv0xohwE6V/Fnj cDz69TeRRDBnqicytG3dITiVlCunPtePANC/x6F+I6txkMj+euHWsxt0rR9Pg55OZWUxRe XO71V2N7BQTAPI1lgz9+y6gCawMWssS57BuUmbGDZe7TbngTdGH4j3EMcLMU2NOJRaHm0q 6Za50CyxTnyhiIMwqA/IelCSm+7YEKJnnhmNWJ2qu++zgzkniMdYVxVjIkAYSqrKy3mfPf Zf6bw3ltVhpxjDRfEdvCeqJ8qF88E7piLvZ2cnQynn7f9s178vI0g2Pq0yJ4Or3Q== Received: by recvd-5577bcb48c-pd8nc with SMTP id recvd-5577bcb48c-pd8nc-1-671615CD-2C 2024-10-21 08:50:21.79185698 +0000 UTC m=+3336865.769144626 Received: from herokuapp.com (unknown) by geopod-ismtpd-27 (SG) with ESMTP id 03UZdOReRKa5wLyKNPO5dQ for ; Mon, 21 Oct 2024 08:50:21.753 +0000 (UTC) Date: Mon, 21 Oct 2024 08:50:21 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 20804 X-Redmine-Issue-Author: kjtsanaktsidis X-Redmine-Issue-Priority: Normal X-Redmine-Sender: kjtsanaktsidis X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 96190 X-SG-EID: =?us-ascii?Q?u001=2Ehtvb0C=2FfA7uJxza5ajJoGjWf7D35DJhKe7Y94xYuv7SZnqx0qbu=2F70+zV?= =?us-ascii?Q?XRgEUZlB2KACYgzrNXwJOFqD+GI4v+xLlProPhe?= =?us-ascii?Q?RqFaaJyjkouGlbQG5FhIiQYGen2H0vDu5rTdZ7B?= =?us-ascii?Q?+4WZRXrRxLSpVJbCN0B9TjNbq+T2zRZWSCdnKdr?= =?us-ascii?Q?5=2FflpamJCq8e5yHmbOD9XsY7fRA9XaOrUP16gb=2F?= =?us-ascii?Q?K9VxHGxhYhFoZ0VrpJQO8NG4Ux9UNcRCxIeXITj?= =?us-ascii?Q?F1NzVoyVQ+lLrYbEShLYQN1xFQ=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: PUW4XZIVAKSCGCL4ZDMELFTGEOIALRHW X-Message-ID-Hash: PUW4XZIVAKSCGCL4ZDMELFTGEOIALRHW X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:119556] [Ruby master Bug#20804] Stop reserving stack ahead-of-time in on Linux List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "kjtsanaktsidis (KJ Tsanaktsidis) via ruby-core" Cc: "kjtsanaktsidis (KJ Tsanaktsidis)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20804 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20804: Stop reserving stack ahead-of-time in on Linux https://bugs.ruby-lang.org/issues/20804 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In Linux, the main thread generally only gets a small stack mapped in initially. As the application attempts to use more stack memory, the kernel will map in more stack pages. In https://github.com/ruby/ruby/pull/822, we added some logic to force the kernel to eagerly map and fault in the entire stack by writing a fake array near the bottom. This was done in order to fix some cases where heap memory was unexpectedly being allocated in locations close to the stack, which then prevented the stack from growing. I ran into this because this logic needed to be fixed for ASAN (https://github.com/ruby/ruby/pull/11921). However, I actually think we should delete `reserve_stack` entirely, which is the point of this issue. Myself and @rianmcguire had a look at this today and we believe that the original problem was in fact a symptom of a kernel bug. The kernel bug (or at least, what we _think_ was the relevant bug) was fixed in 2017 (https://github.com/torvalds/linux/commit/c204d21f2232d875e36b8774c36ffd027dc1d606) On my machine today, under ruby 3.3.2 (2024-05-30 revision e5a195edf6) and kernel 6.10.12-200.fc40.x86_64 I can no longer reproduce the problem demonstrated by the repro script (https://gist.github.com/csfrancis/46e360d401609275246c). ``` kjtsanaktsidis@kjtsanaktsidis-laptop ~ % ./repro.rb new minimum diff: 140730206072832 (2) new minimum diff: 140725853872128 (4) new minimum diff: 140723732975616 (10) new minimum diff: 140719631585280 (14) new minimum diff: 140719552581632 (69) new minimum diff: 140719410409472 (159) new minimum diff: 140719327940608 (1191) new minimum diff: 140719326601216 (3111) new minimum diff: 140719312199680 (6098) ``` Performing this kind of stack reservation actually causes _other_ problems - if RLIMIT_STACK is set to a high value, performing the eager mapping like this can fail for lack of real memory ``` kjtsanaktsidis@kjtsanaktsidis-laptop ~ % ulimit -s 1000000000 kjtsanaktsidis@kjtsanaktsidis-laptop ~ % ruby -e "puts 'hi'" zsh: segmentation fault (core dumped) ruby -e "puts 'hi'" ``` So, therefore, I believe the right thing to do is to just delete `reserve_stack`. Are there any objections to doing this? -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/