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

[Guinevere Larsen <guinevere@redhat.com>]

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.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers