[v3] gdb/testsuite: add test for memory requirements of gcore
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gdb_build--master-arm |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 |
fail
|
Test failed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-arm |
fail
|
Test failed
|
Commit Message
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.
---
gdb/testsuite/gdb.base/gcore-memory-usage.c | 53 ++++++++++
gdb/testsuite/gdb.base/gcore-memory-usage.exp | 96 +++++++++++++++++++
2 files changed, 149 insertions(+)
create mode 100644 gdb/testsuite/gdb.base/gcore-memory-usage.c
create mode 100644 gdb/testsuite/gdb.base/gcore-memory-usage.exp
Comments
>>>>> "Guinevere" == Guinevere Larsen <guinevere@redhat.com> writes:
Guinevere> The test runs twice, once with the inferior allocating 4Mb of memory,
Guinevere> and the other allocating 64Mb. My plan was to find the rate at which
Guinevere> things increase based on inferior size, and have that tested to ensure
Guinevere> we're not growing that requirement accidentally, but my testing
Guinevere> actually showed memory requirements going down as the inferior increases,
Guinevere> so instead I just hardcoded that we need less than 2Mb for the command,
Guinevere> and it can be tweaked later if necessary.
This seems fine to me. I didn't understand why it needed to attach, it
seems like just running it would be the same? But also it doesn't
really matter, considering you've done the work.
Approved-By: Tom Tromey <tom@tromey.com>
thanks,
Tom
On 3/4/25 3:19 PM, Tom Tromey wrote:
>>>>>> "Guinevere" == Guinevere Larsen <guinevere@redhat.com> writes:
> Guinevere> The test runs twice, once with the inferior allocating 4Mb of memory,
> Guinevere> and the other allocating 64Mb. My plan was to find the rate at which
> Guinevere> things increase based on inferior size, and have that tested to ensure
> Guinevere> we're not growing that requirement accidentally, but my testing
> Guinevere> actually showed memory requirements going down as the inferior increases,
> Guinevere> so instead I just hardcoded that we need less than 2Mb for the command,
> Guinevere> and it can be tweaked later if necessary.
>
> This seems fine to me. I didn't understand why it needed to attach, it
> seems like just running it would be the same? But also it doesn't
> really matter, considering you've done the work.
>
> Approved-By: Tom Tromey <tom@tromey.com>
>
> thanks,
> Tom
>
I noticed today as I returned from a holiday that I misunderstood the
issue on v2, so I made this small change to the test, to stop it from
falling. I'll push the test on friday if there are no comments since I
think it is a pretty trivial change.
---
diff --git a/gdb/testsuite/gdb.base/gcore-memory-usage.exp
b/gdb/testsuite/gdb.base/gcore-memory-usage.exp
index 1e31578d4a9..db7f270a5e8 100644
--- a/gdb/testsuite/gdb.base/gcore-memory-usage.exp
+++ b/gdb/testsuite/gdb.base/gcore-memory-usage.exp
@@ -59,7 +59,7 @@ proc run_test {megs} {
gdb_test "attach $inferior_pid" "Attaching to.*"
set line [gdb_get_line_number "TAG: BREAK HERE" $::testfile.c]
- gdb_breakpoint "$line" "break at to known line"
+ gdb_breakpoint "${::srcfile}:$line" "break at to known line"
gdb_continue_to_breakpoint "continue to known line"
# Get the important info.
>>>>> "Guinevere" == Guinevere Larsen <guinevere@redhat.com> writes:
Guinevere> I noticed today as I returned from a holiday that I misunderstood the
Guinevere> issue on v2, so I made this small change to the test, to stop it from
Guinevere> falling. I'll push the test on friday if there are no comments since I
Guinevere> think it is a pretty trivial change.
Yeah, you should just go ahead, thanks.
Tom
On 3/5/25 5:21 PM, Tom Tromey wrote:
>>>>>> "Guinevere" == Guinevere Larsen <guinevere@redhat.com> writes:
> Guinevere> I noticed today as I returned from a holiday that I misunderstood the
> Guinevere> issue on v2, so I made this small change to the test, to stop it from
> Guinevere> falling. I'll push the test on friday if there are no comments since I
> Guinevere> think it is a pretty trivial change.
>
> Yeah, you should just go ahead, thanks.
>
> Tom
>
alright, pushed with the change, thank you!
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
On 3/11/25 1:14 PM, Simon Marchi wrote:
> 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
>
The original test just hardcoded 4 Mbs of memory for the 64Mb case (and
only had that case). I tried to make it more useful by analyzing the
growth of memory usage instead, but there seems to be no growth in
memory... So I think it's fine to just bump it up.
new file mode 100644
@@ -0,0 +1,53 @@
+/* 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 <http://www.gnu.org/licenses/>. */
+
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+
+int spin = 1;
+
+int
+main (int argc, char **argv)
+{
+ /* Small quality of life thing for people re-running tests
+ manually. */
+ if (argc < 2)
+ {
+ printf("Usage: %s [Megs]", argv[0]);
+ return 1;
+ }
+ /* 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);
+
+ /* Setup an alarm, in case something goes wrong with testing. */
+ alarm (300);
+
+ /* Wait a long time so GDB can attach to this.
+ We need to have the second statement inside of the loop
+ to sidestep PR breakpoints/32744. */
+ while (spin)
+ sleep (1);/* TAG: BREAK HERE */
+
+ /* Let's be nice citizens :). */
+ free (p);
+ return 0;
+}
new file mode 100644
@@ -0,0 +1,96 @@
+# 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 <http://www.gnu.org/licenses/>.
+
+# Test that gcore doesn't end up using excessive memory.
+
+require {istarget "*-*-linux*"}
+require can_spawn_for_attach
+
+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 corefile [standard_output_file "${::testfile}.core"]
+ set inferior_spawn_id [spawn_wait_for_attach [list "$::binfile $megs"]]
+ set inferior_pid [spawn_id_get_pid $inferior_spawn_id]
+ set gdb_pid [exp_pid -i [board_info host fileid]]
+
+ gdb_test "attach $inferior_pid" "Attaching to.*"
+ set line [gdb_get_line_number "TAG: BREAK HERE" $::testfile.c]
+ gdb_breakpoint "$line" "break at to known line"
+ gdb_continue_to_breakpoint "continue to known line"
+
+ # Get the important info.
+ 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 too much memory"
+
+ gdb_test_no_output "set spin=0" "Allow program to exit"
+ }
+ 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