From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id PUFVEK1h0GeyQwwAWB0awg (envelope-from ) for ; Tue, 11 Mar 2025 12:15:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741709741; bh=sTwHV3Kx2u/OdatE1oT7rFa4jIwRkpN2osAkHXK/ZRE=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=NDL7ZJmgGeUldZjsjSGczR7BZwY19mw1om+8utQliH+W8MG8SBc1Uy1dPqEa/SgHl Cra5KC5216JD13DP9fTsOSaPxtsNFxXSJMQgtR8t45bvUZYVYZFVll9KcUIwSRtYLf rNdlqEjyUNcakAlEz3Dbb4q5SmO8q0Bi/neNtiFU= Received: by simark.ca (Postfix, from userid 112) id 3121D1E105; Tue, 11 Mar 2025 12:15:41 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.0 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=MmAmO3s9; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=vdIJdND2; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 93FEF1E08E for ; Tue, 11 Mar 2025 12:15:40 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 27A493857718 for ; Tue, 11 Mar 2025 16:15:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 27A493857718 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=MmAmO3s9; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=vdIJdND2 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id E9FAC385783B for ; Tue, 11 Mar 2025 16:14:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E9FAC385783B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E9FAC385783B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741709674; cv=none; b=wAyC+CYwJ8+egWDC4hkOc4J8o05YZdsHvtsZHvIDKqmK1/+dbrvlv+nBgntcQdhbLXPAMdfpO5GfQzez6cTYOR4avlwFLSkwZlylbBQTudvtJ5EvhqIF8OLGnJaYlQlMjWDIo95WT6NvbA7hg4KXgrcLeYgEskXFhkgPLDUpJP8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741709674; c=relaxed/simple; bh=sTwHV3Kx2u/OdatE1oT7rFa4jIwRkpN2osAkHXK/ZRE=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=gfaWDQyoulwxn2lfgcriifThlOa0mSV4ZS+2S5pv899hnHemjTYwPPmVm8/LJhg62ItsTtVzqik8IVMecv+tGwiY0FKz+cIXrH904z2dsoQcIfwi7hwpYBMDfzto8s4OiLo2Cj8dLOSxjoGp7O4jitZCcumGUFAX7Oq7gBTlnao= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E9FAC385783B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741709673; bh=sTwHV3Kx2u/OdatE1oT7rFa4jIwRkpN2osAkHXK/ZRE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=MmAmO3s9NOsVUfqLsC5SB8ILG6AKu6UXIqSPuJEGz8QAzzJifLf10MKvOG4phzNZ4 TmGE3HDhaLlYck1lr7f95M1q7j5QasImMjYwtZp7EHl1UXV20jcSGiD7JO3WKQiw0t hnDrWT7JSykQ7At1FdpRTY4YzTstHLgiIN5ObBuI= Received: by simark.ca (Postfix, from userid 112) id 8F6921E105; Tue, 11 Mar 2025 12:14:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741709672; bh=sTwHV3Kx2u/OdatE1oT7rFa4jIwRkpN2osAkHXK/ZRE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=vdIJdND2yrkHIgVRYyigcCLeb6Yh3owYgE37wFarFaxuQ7xh4SNGY2RSBy3coEf5y wn9UTRLHqv22Lep7tyupC67zS+xhFEEYIAxZx82lwetwZGisENRilgxYGhsDr6/Mnk GPEYIohxOBbb1szb2Afq8bap2gqe4OZBIEZ3si/U= Received: from [172.16.0.106] (96-127-217-162.qc.cable.ebox.net [96.127.217.162]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id BA57F1E08E; Tue, 11 Mar 2025 12:14:32 -0400 (EDT) Message-ID: <52f3a732-7866-45e8-9070-8f2aa143c5e7@simark.ca> Date: Tue, 11 Mar 2025 12:14:31 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] gdb/testsuite: add test for memory requirements of gcore To: Guinevere Larsen , gdb-patches@sourceware.org References: <20250225134544.2129276-1-guinevere@redhat.com> <20250226175058.3060581-2-guinevere@redhat.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20250226175058.3060581-2-guinevere@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2/26/25 12:50 PM, Guinevere Larsen wrote: > For a long time, Fedora has been carrying an out-of-tree patch with a > similar test to the one proposed in this patch, that ensures that the > memory requirements don't grow with the inferior's memory. It's been > so long that the context for why this test exists has been lost, but > it looked like it could be interesting for upstream. > > The test runs twice, once with the inferior allocating 4Mb of memory, > and the other allocating 64Mb. My plan was to find the rate at which > things increase based on inferior size, and have that tested to ensure > we're not growing that requirement accidentally, but my testing > actually showed memory requirements going down as the inferior increases, > so instead I just hardcoded that we need less than 2Mb for the command, > and it can be tweaked later if necessary. > --- > > Linaro flagged an issue in v2, where GDB couldn't set a breakpoint in > line 51 (where i was incremented). That sounds like a gcc issue, > optimizing i away because it was unused, but to avoid having this come > and go as GCC changes, I changed to set a bp directly on the sleep line. > This should work now. On my CI, I see: The gcore command used 2 Mb (3004 Kb) FAIL: gdb.base/gcore-memory-usage.exp: 4 Mb: gdb did not use too much memory The gcore command used 2 Mb (3004 Kb) FAIL: gdb.base/gcore-memory-usage.exp: 64 Mb: gdb did not use too much memory Locally if I try to build with the same configuration, I get: The gcore command used 1 Mb (1640 Kb) PASS: gdb.base/gcore-memory-usage.exp: 64 Mb: gdb did not use too much memory I don't know why there's a difference. It's not the same distribution or tool versions, it could be a lot of things. Note that I build with Asan, UBSan and -D_GLIBCXX_DEBUG=1, all of which can raise the memory usage. Also, on the CI, the workers are containers, so perhaps it does something to the reported stats. I don't really know if I should investigate that further or just bump the threshold for "too much memory". Simon