glibc: Add 8GB VM usage cap for usermode test suite

We've noticed that:

MACHINE=qemuarm oe-selftest -r glibc.GlibcSelfTest.test_glibc

ends up with one process growing to about the size of system memory
and triggering the OOM killer. This has been taking out other builds
running on the system on the autobuilders and is one cause of our
intermittent failures.

This was tracked down to:

WORKDIR=XXX/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/glibc-testsuite/2.33-r0
BUILDDIR=$WORKDIR/build-arm-poky-linux-gnueabi QEMU_SYSROOT=$WORKDIR/recipe-sysroot
QEMU_OPTIONS="$WORKDIR/recipe-sysroot-native/usr/bin/qemu-arm -r 3.2.0" \
$WORKDIR/check-test-wrapper user env GCONV_PATH=$BUILDDIR/iconvdata LOCPATH=$BUILDDIR/localedata LC_ALL=C $BUILDDIR/elf/ld-linux-armhf.so.3 \
    --library-path $BUILDDIR:$BUILDDIR/math:$BUILDDIR/elf:$BUILDDIR/dlfcn:$BUILDDIR/nss:$BUILDDIR/nis:$BUILDDIR/rt:$BUILDDIR/resolv:$BUILDDIR/mathvec:$BUILDDIR/support:$BUILDDIR/nptl \
    $BUILDDIR/nptl/tst-pthread-timedlock-lockloop

although other glibc tests appear to use 16GB of memory before failing
anyway. By capping the VM size to 8GB, we see the same number of failures
but no OOM situations. There may be some issue in qemu or the test which
could be improved to avoid this entirely but this provides a necessary
and useful safeguard to other builds and doensn't appear to make the
situation worse.

On a loaded system OOM may not occur as the test timeout may be triggered
first. An experiment with a 5GB limit showed an additional 7 failures.

(From OE-Core rev: 58d4f669bd46805669daf87626350fe9359feca5)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

0 files changed, 0 insertions, 0 deletions