From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KOEjKxLNvGeeZjwAWB0awg (envelope-from ) for ; Mon, 24 Feb 2025 14:48:34 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=JmUY7TOW; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A54851E105; Mon, 24 Feb 2025 14:48:34 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 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 C97881E05C for ; Mon, 24 Feb 2025 14:48:33 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7634F3858CD9 for ; Mon, 24 Feb 2025 19:48:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7634F3858CD9 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=JmUY7TOW Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 5D9013858D33 for ; Mon, 24 Feb 2025 19:47:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5D9013858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5D9013858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1740426476; cv=none; b=LtD0j2uQfZxv6etGLhvs4K+QtXQVLwTFjJHuMg9rNUMFbP7Fvne4t9KYS/Kp8Qnm22C5jo3Jl2EAV5mpLkrMwTVIZMjCeJ1hcBv8wQbSlEDeNxVaLmS1Bwyxsccio3GBYg7VYh6x/+pOLZXqsnzHj7w/MEzVPPbDbE8KaROXHWw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1740426476; c=relaxed/simple; bh=EzrSRl/MkPIiWZsCQXHBnj7MzFns70qNv/3Uyy0pTQs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=m/1OYO0mUZu5Kx9+2F3pr3EHLN4NkMmJAUlToW8qsNQIuTND/bLgXhBoZSiSw85iI4bnOt9JVgtJI9KM6F9wU3vOzzVklRcNtMIAjTm7MJZafUP6iU0Aa/KcpOjSh8UBPwz1e3xpjNPXzUZPC5h0w06U/MYBUBusqje6jO3DrVg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5D9013858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740426476; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G4yVoZymHECry8oeJ4F60YZbauEd7IB33uI+O8sDC+M=; b=JmUY7TOWbTwwsYBlJLKWoD4/fPso5elqXe08Sed/OyjrDWOVdZ8pV4czBVo2Ql1V1EuiTg FpfD22KHAYWzbHuH4iWk7W1CJjW5fsuKEsNirfEUDJk/R0V/1CpViuMrObYBWTD0mvptD/ FQex6RzweW/zqQLVTw7wwLYAsXaw4Cw= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-643-o1atzh-qNKa95LcToc6DWg-1; Mon, 24 Feb 2025 14:47:54 -0500 X-MC-Unique: o1atzh-qNKa95LcToc6DWg-1 X-Mimecast-MFC-AGG-ID: o1atzh-qNKa95LcToc6DWg_1740426473 Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-21f6cb3097bso127342185ad.3 for ; Mon, 24 Feb 2025 11:47:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740426473; x=1741031273; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=G4yVoZymHECry8oeJ4F60YZbauEd7IB33uI+O8sDC+M=; b=FdP+zKX2L9an9v/yBiuqIVDGTt2Me4PxFOnUzc5cMHQSGYM5hn5xlZGXw3oTXrPHAW UDILeyv0KghhOZOYgvC3OrDt8hi06ZQSBiErhihSOq33ZaCGqTpkJj3G4kA2Svou1ncg QfTomwPNUJ8PkTPNky7kxQCSITO+2vUHgUucjDEwv51rB4idYjss4c7zOzJltwmAen/P M2nqZqjaHT2m+/TsjpV8G8h28+q60nBCmZGMaKruXmjCB2S3pbd/jRiDot6iuMCSi0Di vy72iSDda5JRnuBJjcOIBcKAB7oS8m99vlkY3H1VbxjqltFfUXqTDfR6vLVJD1Nb1THQ QlvA== X-Forwarded-Encrypted: i=1; AJvYcCWbf6N6WXAJIjo8EEpZNTgXvTDpCviqLCBzR5FQ+5meiHcAe2tmHQp1xctvagBDjWMPFPfz7fDmdbwgqg==@sourceware.org X-Gm-Message-State: AOJu0YxLhdLPAIbKbbRHHQdWD1+Ja/OHCWLoAvzt1v9PxCCMwjTe9y3j zfxvmwY92tx86Kk9BiFb3PdbjuhCg0nMLo1UIcILo9fx7ma6Xl5U/QWdW6YVu3Ev/ageP5QHVqx 4TMQMpaRvfCEw3IX11iuo6DOuklFkStgHp/+Qa4UoosMLe1RjCEXs0OXjvPhD7Sv6XAw= X-Gm-Gg: ASbGncv2+KlNV5sA6bngB1URVrBaTBrXPevAv4estVvgiLUPohCQRONqyOsO2rLTBM7 GO1+Cl5Pv+NrBj2IW4+js3H1izIATEANSHrkTfAWaIcymwy91VSvB4UcvPsY7K0hKU6i+nvXTI2 GQh+Wvz9J+wnXunU6R9OUItqKDgvmMNYgJqFgSCrOBH3IHC4IxQ6oiyFxmrOFDDB3wSFOLgmsqc lTzM2SfkAU+84ZGMfEjOxD9m0NR0b6Aa+o+/BYyGXrSGRH7nGba7PulBhIJ4l34Y72sCJIYkjG0 BfY6FZBJr5CLStz+LusitJ5CX9c= X-Received: by 2002:a17:902:f546:b0:215:6816:6345 with SMTP id d9443c01a7336-221a0ed7891mr215046225ad.16.1740426472959; Mon, 24 Feb 2025 11:47:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IFQDqKPsXd7AwiWWwmNwJtf+ay2b0q1Qanu9+83whjOBBAsb+MGJ5iALdatwrP7lc0ZOBTOjw== X-Received: by 2002:a17:902:f546:b0:215:6816:6345 with SMTP id d9443c01a7336-221a0ed7891mr215045955ad.16.1740426472565; Mon, 24 Feb 2025 11:47:52 -0800 (PST) Received: from ?IPV6:2804:14d:8084:9a69::1002? ([2804:14d:8084:9a69::1002]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7347a81edb9sm13870b3a.146.2025.02.24.11.47.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Feb 2025 11:47:52 -0800 (PST) Message-ID: <9f4f8393-1dae-4865-8da4-778ef9c139a9@redhat.com> Date: Mon, 24 Feb 2025 16:47:49 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/testsuite: add test for memory requirements of gcore To: Tom de Vries , gdb-patches@sourceware.org References: <20250224140407.252987-1-guinevere@redhat.com> <5f6b3d35-bb54-45d3-9256-4c8714b9fc22@suse.de> From: Guinevere Larsen In-Reply-To: <5f6b3d35-bb54-45d3-9256-4c8714b9fc22@suse.de> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EOrsbRIOOrco7zbPQwFn93562QS742gyXViW37F6BtQ_1740426473 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/24/25 12:24 PM, Tom de Vries wrote: > On 2/24/25 15:04, 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. > > I tried out the test-case, and it passed for me, but after doing: > ... > $ echo "1" | sudo tee /proc/sys/kernel/yama/ptrace_scope > ... > I get: > ... > (gdb) attach 29408^M > Attaching to program: > /data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/gcore-memory-usage/gcore-memory-usage, > process 29408^M > ptrace: Operation not permitted.^M > (gdb) PASS: gdb.base/gcore-memory-usage.exp: 4 Mb: attach 29408 > PASS: gdb.base/gcore-memory-usage.exp: 4 Mb: before: Managed to read > the memory usage > gcore > /data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/gcore-memory-usage/gcore-memory-usage.core^M > You can't do that without a process to debug.^M > (gdb) FAIL: gdb.base/gcore-memory-usage.exp: 4 Mb: create the corefile > ... > > So, this is missing "require can_spawn_for_attach". Ah, thanks for spotting that. I'll fix this for v2 (that may take a minute given Andrew's comments)... -- Cheers, Guinevere Larsen She/Her/Hers > > Thanks, > - Tom > >> --- >>   gdb/testsuite/gdb.base/gcore-memory-usage.c   | 37 +++++++ >>   gdb/testsuite/gdb.base/gcore-memory-usage.exp | 97 +++++++++++++++++++ >>   2 files changed, 134 insertions(+) >>   create mode 100644 gdb/testsuite/gdb.base/gcore-memory-usage.c >>   create mode 100644 gdb/testsuite/gdb.base/gcore-memory-usage.exp >> >> diff --git a/gdb/testsuite/gdb.base/gcore-memory-usage.c >> b/gdb/testsuite/gdb.base/gcore-memory-usage.c >> new file mode 100644 >> index 00000000000..514fdb905cf >> --- /dev/null >> +++ b/gdb/testsuite/gdb.base/gcore-memory-usage.c >> @@ -0,0 +1,37 @@ >> +/* This testcase is part of GDB, the GNU debugger. >> + >> +   Copyright 2025 Free Software Foundation, Inc. >> + >> +   This program is free software; you can redistribute it and/or modify >> +   it under the terms of the GNU General Public License as published by >> +   the Free Software Foundation; either version 3 of the License, or >> +   (at your option) any later version. >> + >> +   This program is distributed in the hope that it will be useful, >> +   but WITHOUT ANY WARRANTY; without even the implied warranty of >> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the >> +   GNU General Public License for more details. >> + >> +   You should have received a copy of the GNU General Public License >> +   along with this program.  If not, see >> .  */ >> + >> + >> +#include >> +#include >> +#include >> + >> +int main(int argc, char **argv) >> +{ >> +  /* Use argv to calculate how many megabytes to allocate. >> +     Do this to see how much gcore memory usage increases >> +     based on inferior dynamic memory.  */ >> +  int megs = atoi (argv[1]); >> +  char *p = malloc (megs * 1024 * 1024); >> + >> +  /* Wait a long time so GDB can attach to this.  */ >> +  sleep (10); >> + >> +  /* Let's be nice citizens :).  */ >> +  free (p); >> +  return 0; >> +} >> diff --git a/gdb/testsuite/gdb.base/gcore-memory-usage.exp >> b/gdb/testsuite/gdb.base/gcore-memory-usage.exp >> new file mode 100644 >> index 00000000000..cdb6d73c11b >> --- /dev/null >> +++ b/gdb/testsuite/gdb.base/gcore-memory-usage.exp >> @@ -0,0 +1,97 @@ >> +# Copyright (C) 2025 Free Software Foundation, Inc. >> + >> +# This program is free software; you can redistribute it and/or modify >> +# it under the terms of the GNU General Public License as published by >> +# the Free Software Foundation; either version 3 of the License, or >> +# (at your option) any later version. >> +# >> +# This program is distributed in the hope that it will be useful, >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the >> +# GNU General Public License for more details. >> +# >> +# You should have received a copy of the GNU General Public License >> +# along with this program.  If not, see . >> + >> +# Test that gcore doesn't end up using excessive memory. >> + >> +require {istarget "*-*-linux*"} >> + >> +standard_testfile >> + >> +if {[build_executable "failed to prepare" $testfile $srcfile >> {debug}] == -1} { >> +    return -1 >> +} >> + >> +# Read the proc_pid_status page, to find how much memory the given >> +# PID is using.  This is meant to be used to find the >> +# memory usage for the GDB in this test. >> +# Returns memory usage in Kb, or -1 if it couldn't be found. >> +proc get_mem_usage {pid prefix} { >> +    set fd [open "/proc/$pid/status"] >> +    set memory -1 >> +    while {[gets $fd line] != -1} { >> +    if {[regexp {VmSize:\s*([0-9]+) kB} $line full mem]} { >> +        set memory $mem >> +        break >> +    } >> +    } >> +    close $fd >> + >> +    gdb_assert {$memory != -1} "$prefix: Managed to read the memory >> usage" >> + >> +    return $memory >> +} >> + >> +# This proc restarts GDB, runs the inferior with the desired >> +# amount of memory, then checks how much memory is necessary >> +# to run the gcore command.  It will return -1 if the gcore >> +# command fails, 0 otherwise. >> +proc run_test {megs} { >> +    with_test_prefix "$megs Mb" { >> +    clean_restart $::testfile >> + >> +    set bin [standard_output_file $::testfile] >> +    set corefile [standard_output_file "${::testfile}.core"] >> +    set inferior_pid [eval exec $bin $megs &] >> +    set gdb_pid [exp_pid -i [board_info host fileid]] >> + >> +    # wait for memory allocation to finish. >> +    sleep 1 >> + >> +    # Get the important info. >> +    gdb_test "attach $inferior_pid" "Attaching to.*" >> +    set mem_before [get_mem_usage $gdb_pid before] >> +    if {![gdb_gcore_cmd $corefile "create the corefile"]} { >> +        return -1 >> +    } >> +    set mem_after [get_mem_usage $gdb_pid after] >> + >> +    # Do the main part of the test: How much is the memory >> +    # usage of GDB going to grow after using the gcore command. >> +    set diff_k [expr $mem_after - $mem_before] >> +    set diff [expr $diff_k/1024] >> +    verbose -log "The gcore command used $diff Mb ($diff_k Kb)" >> +    # The original plan was to compare to a multiple of MEGS >> +    # but since the requirements don't seem to go up as the >> +    # inferior allocated more memory, we instead just hardcode >> +    # 2 megs, since sometimes 1 is used. >> +    gdb_assert {$diff < 2} \ >> +        "gdb did not use as much memory as the inferior" >> + >> +    # Kill the inferior so we don't have to wait until the process >> +    # finishes. >> +    gdb_test "signal SIGKILL" ".*The program no longer exists." >> +    } >> +    return 0 >> +} >> + >> +# If we couldn't create the first corefile, there's no point >> +# in running the second part of the test. >> +if {[run_test 4] != 0} { >> +    return >> +} >> +# Surprisingly enough, the larger inferior doesn't seem to use >> +# any extra memory, it usually uses less memory.  Which is good, >> +# it means our memory requirements aren't growing with the inferior. >> +run_test 64 >