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

[Simon Marchi <simark@simark.ca>]

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