[PATCH] Fix detection of setrlimit in libstdc++ testsuite
Wed Nov 11 16:56:00 GMT 2015
This patch fixes an obscure cross-testing problem that crashed (OOMed) our boards at Linaro. Several tests in libstdc++ (e.g., ) 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.]
Therefore, when testing a cross toolchain, the test  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  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?
I didn't go as far as enabling setenv/locale tests when cross-testing libstdc++ because I remember of issues with generating locales in cross-built glibc. In any case, locale tests are unlikely to OOM the test board the way that absence of setrlimit does.
[*] Cross-testing using user-mode QEMU made 27_io/fpos/14775.cc execution test to FAIL. This test uses setrlimit set max file size, and is misbehaving only under QEMU. I believe this a QEMU issue with not handling setrlimit correctly.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1982 bytes
Desc: not available
More information about the Gcc-patches