Re: [PATCH] Fix detection of setrlimit in libstdc++ testsuite

[Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>]

> On Apr 5, 2016, at 2:20 PM, Jonathan Wakely <jwakely@redhat.com> wrote:
> 
>> This patch fixes an obscure cross-testing problem that crashed (OOMed) our boards at Linaro.  Several tests in libstdc++ (e.g., [1]) limit themselves to some reasonable amount of RAM and then try to allocate 32 gigs.  Unfortunately, the configure test that checks presence of setrlimit is rather strange: if target is native, then try compile file with call to setrlimit -- if compilation succeeds, then use setrlimit, otherwise, ignore setrlimit.  The strange part is that the compilation check is done only for native targets, as if cross-toolchains can't generate working executables.  [This is rather odd, and I might be missing some underlaying caveat.]
> 
> I went spelunking, and the IS_NATIVE check has been there since
> r70167, which replaced:
> 
> if test  x"$GLIBCXX_IS_CROSS_COMPILING" = xfalse; then
>   # Do checks for memory limit functions.
>   GLIBCXX_CHECK_SETRLIMIT
> 
> That arrived in r68067, but that seems to eb just a refactoring, and I
> got lost tracking it further.
> 
> So there has been a similar check since at least 2003.
> 
>> Therefore, when testing a cross toolchain, the test [1] still tries to allocate 32GB of RAM with no setrlimit restrictions.  On most targets that people use for cross-testing this is not an issue because either
>> - the target is 32-bit, so there is no 32GB user-space to speak of, or
>> - the target board has small amount of RAM and no swap, so allocation immediately fails, or
>> - the target board has plenty of RAM, so allocating 32GB is not an issue.
>> 
>> However, if one is testing on a 64-bit board with 16GB or RAM and 16GB of swap, then one gets into an obscure near-OOM swapping condition.  This is exactly the case with cross-testing aarch64-linux-gnu toolchains on APM Mustang.
>> 
>> The attached patch removes "native" restriction from configure test for setrlimit.  This enables setrlimit restrictions on the testsuite, and the test [1] expectedly fails to allocate 32GB due to setrlimit restriction.
>> 
>> I have tested it on x86_64-linux-gnu and i686-linux-gnu native toolchains, and aarch64-linux-gnu and arm-linux-gnueabi[hf] cross-toolchains with no regressions [*].
>> 
>> OK to commit?
> 
> This issue has been present for well over a decade so it doesn't seem
> critical to fix in stage4, but as it only affects the testsuite I am
> OK with the change if the RMs have no objections.

Hi Jonathan,

This issue dropped off my patch queue.  The original patch still applies without conflicts, and I'm retesting it on fresh mainline -- both cross and native.

OK to commit if no regressions?

Thanks,

--
Maxim Kuvyrkov
www.linaro.org