Re: [PATCH v3] gdb/testsuite: add test for memory requirements of gcore

Simon Marchi
2025-03-11T16:15:41Z

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