From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80362 invoked by alias); 11 Nov 2015 16:56:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 80349 invoked by uid 89); 11 Nov 2015 16:56:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wm0-f52.google.com Received: from mail-wm0-f52.google.com (HELO mail-wm0-f52.google.com) (74.125.82.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 11 Nov 2015 16:56:35 +0000 Received: by wmww144 with SMTP id w144so52736505wmw.0 for ; Wed, 11 Nov 2015 08:56:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=KLzKExLkFrqUEKE0ngTuqyh52WS9zqAc6BUugl2DamM=; b=bsY4MH/eLw+o4c5ohhGbleOa/Gq9d+HG4tOYb3T2Vy7/i2ydw/Jb58blDLk1NxP054 kd8XQGv0cMli7BW8amonGMqywhhOXg5aGc4gJyEggOYozXQ87SSE0locK5DOM0x15gW2 lrQuurU3Yy3VNorPmYK9WyPZvM5+sdfcN0yS2wfiqLez1roDu6D6nhOFAu9vAO7G5jtO tJAEvKfbRbbRxXCD7t4qgRIOLfaqRIfDapSGvP2oAsP3mVpaZsbZ5Wt+RejbMdHp+62j yjt+jm5u8L9Y0vbJUV9rTg3SiFHqfdxgYgdw8edHynld3ZV1NM1Wo8aNzyeGr09onkaS JKCw== X-Gm-Message-State: ALoCoQmzwN9hJsLdwgE4B6zM8KYxb3fmAec4xFX2CHN4Y4GCOfyxq8q3+u+KEyxgb+FmkfRczaAU X-Received: by 10.28.226.86 with SMTP id z83mr19562775wmg.77.1447260992798; Wed, 11 Nov 2015 08:56:32 -0800 (PST) Received: from [192.168.1.65] (ppp91-76-176-149.pppoe.mtu-net.ru. [91.76.176.149]) by smtp.gmail.com with ESMTPSA id m135sm28442773wmb.0.2015.11.11.08.56.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Nov 2015 08:56:31 -0800 (PST) From: Maxim Kuvyrkov Content-Type: multipart/mixed; boundary="Apple-Mail=_76821EC8-F78B-4DC9-90C7-B772666C2B08" Subject: [PATCH] Fix detection of setrlimit in libstdc++ testsuite Message-Id: <28F74808-E037-4192-BB5E-A0492BE31172@linaro.org> Date: Wed, 11 Nov 2015 16:56:00 -0000 To: GCC Patches Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-SW-Source: 2015-11/txt/msg01399.txt.bz2 --Apple-Mail=_76821EC8-F78B-4DC9-90C7-B772666C2B08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Content-length: 2357 Hi, 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. Unfortu= nately, the configure test that checks presence of setrlimit is rather stra= nge: if target is native, then try compile file with call to setrlimit -- i= f compilation succeeds, then use setrlimit, otherwise, ignore setrlimit. T= he strange part is that the compilation check is done only for native targe= ts, as if cross-toolchains can't generate working executables. [This is ra= ther odd, and I might be missing some underlaying caveat.] Therefore, when testing a cross toolchain, the test [1] still tries to allo= cate 32GB of RAM with no setrlimit restrictions. On most targets that peop= le 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 immed= iately 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 s= wap, then one gets into an obscure near-OOM swapping condition. This is ex= actly the case with cross-testing aarch64-linux-gnu toolchains on APM Musta= ng. The attached patch removes "native" restriction from configure test for set= rlimit. 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 re= gressions [*]. OK to commit? I didn't go as far as enabling setenv/locale tests when cross-testing libst= dc++ because I remember of issues with generating locales in cross-built gl= ibc. In any case, locale tests are unlikely to OOM the test board the way = that absence of setrlimit does. [1] 27_io/ios_base/storage/2.cc [*] Cross-testing using user-mode QEMU made 27_io/fpos/14775.cc execution t= est to FAIL. This test uses setrlimit set max file size, and is misbehavin= g only under QEMU. I believe this a QEMU issue with not handling setrlimit= correctly. -- Maxim Kuvyrkov www.linaro.org --Apple-Mail=_76821EC8-F78B-4DC9-90C7-B772666C2B08 Content-Disposition: attachment; filename=0001-Use-setrlimit-for-testing-libstdc-in-cross-toolchain.patch Content-Type: application/octet-stream; name="0001-Use-setrlimit-for-testing-libstdc-in-cross-toolchain.patch" Content-Transfer-Encoding: quoted-printable Content-length: 2236 >From d4330fb411366ae39865c303c92e35cec73543c9 Mon Sep 17 00:00:00 2001=0A= From: Maxim Kuvyrkov =0A= Date: Fri, 30 Oct 2015 14:05:40 +0100=0A= Subject: [PATCH] Use setrlimit for testing libstdc++ in cross toolchains=0A= =0A= * acinclude.m4 (GLIBCXX_CONFIGURE_TESTSUITE): Check for presence of=0A= setrlimit on both native and cross targets.=0A= * configure: Regenerate.=0A= =0A= Change-Id: I72745beedc7d8976e0c142806348450785face82=0A= ---=0A= libstdc++-v3/acinclude.m4 | 6 +++---=0A= libstdc++-v3/configure | 4 ++--=0A= 2 files changed, 5 insertions(+), 5 deletions(-)=0A= =0A= diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4=0A= index abf2e93..aed5be8 100644=0A= --- a/libstdc++-v3/acinclude.m4=0A= +++ b/libstdc++-v3/acinclude.m4=0A= @@ -632,10 +632,10 @@ dnl baseline_dir=0A= dnl baseline_subdir_switch=0A= dnl=0A= AC_DEFUN([GLIBCXX_CONFIGURE_TESTSUITE], [=0A= - if $GLIBCXX_IS_NATIVE ; then=0A= - # Do checks for resource limit functions.=0A= - GLIBCXX_CHECK_SETRLIMIT=0A= + # Do checks for resource limit functions.=0A= + GLIBCXX_CHECK_SETRLIMIT=0A= =20=0A= + if $GLIBCXX_IS_NATIVE ; then=0A= # Look for setenv, so that extended locale tests can be performed.=0A= GLIBCXX_CHECK_STDLIB_DECL_AND_LINKAGE_3(setenv)=0A= fi=0A= diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure=0A= index 1eb6db4..614e703 100755=0A= --- a/libstdc++-v3/configure=0A= +++ b/libstdc++-v3/configure=0A= @@ -78612,8 +78612,7 @@ $as_echo "$ac_cv_x86_rdrand" >&6; }=0A= =20=0A= # This depends on GLIBCXX_ENABLE_SYMVERS and GLIBCXX_IS_NATIVE.=0A= =20=0A= - if $GLIBCXX_IS_NATIVE ; then=0A= - # Do checks for resource limit functions.=0A= + # Do checks for resource limit functions.=0A= =20=0A= setrlimit_have_headers=3Dyes=0A= for ac_header in unistd.h sys/time.h sys/resource.h=0A= @@ -78842,6 +78841,7 @@ $as_echo "#define _GLIBCXX_RES_LIMITS 1" >>confdefs= .h=0A= $as_echo "$ac_res_limits" >&6; }=0A= =20=0A= =20=0A= + if $GLIBCXX_IS_NATIVE ; then=0A= # Look for setenv, so that extended locale tests can be performed.=0A= =20=0A= { $as_echo "$as_me:${as_lineno-$LINENO}: checking for setenv declaration= " >&5=0A= --=20=0A= 1.9.1=0A= =0A= --Apple-Mail=_76821EC8-F78B-4DC9-90C7-B772666C2B08--