From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13561 invoked by alias); 10 Dec 2015 13:48:13 -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 13334 invoked by uid 89); 10 Dec 2015 13:48:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wm0-f47.google.com Received: from mail-wm0-f47.google.com (HELO mail-wm0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 10 Dec 2015 13:47:50 +0000 Received: by mail-wm0-f47.google.com with SMTP id u63so24637078wmu.0 for ; Thu, 10 Dec 2015 05:47:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9TiZlsX+3Znt6oXhv3SO0dDo1wCzraMmEDwlrsShbZg=; b=JDyNCT8FktJicylLLuVsyKn/EnA0KykVlY5mb4Fzs9ZDJolHg6U6iKwwQ/ApixeRKV O4Mar/F7KgerzJ6vmKsytg3w/T5kbalXlEKBtcXQ57eKnHjY79CzMQx9OmuhIosg8ogk 2Ce6agP4/r4Nbe0Dy2kRjnLUVhPHzmZxUotZXSs4DULpSuAMFSC2yW9oiBPh4ySR/oOv +UCjAtHzIyD8WXDpUSDJWU475ziPXvcSn8U89XwoY3lKH1f9I1QRpvRlNTsOep+27ShF /Lkcnp/LC/91ixCgDf8oCVvmf/pC0G8V3K53zd5kNUONPhTFQTwVS+159r2/Wrp1AG8W mKDQ== X-Gm-Message-State: ALoCoQmsG5ENfNsQmnK+mbItiYo59XED4RbvWEznZaxTDW2CAlN1+YQ3XaJTSK+l0p3LqYQVr7WSZ9BIjOaGYLzCZPBPpsryww== X-Received: by 10.194.203.99 with SMTP id kp3mr13059953wjc.3.1449755267504; Thu, 10 Dec 2015 05:47:47 -0800 (PST) Received: from [192.168.1.122] (ip-79-111-236-19.bb.netbynet.ru. [79.111.236.19]) by smtp.gmail.com with ESMTPSA id jm4sm12480687wjb.7.2015.12.10.05.47.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 05:47:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: [PATCH] Fix detection of setrlimit in libstdc++ testsuite From: Maxim Kuvyrkov In-Reply-To: <28F74808-E037-4192-BB5E-A0492BE31172@linaro.org> Date: Thu, 10 Dec 2015 13:48:00 -0000 Cc: Mike Stump Content-Transfer-Encoding: quoted-printable Message-Id: <9B4A743A-A0A2-4B3F-8564-36685071C1C8@linaro.org> References: <28F74808-E037-4192-BB5E-A0492BE31172@linaro.org> To: GCC Patches X-SW-Source: 2015-12/txt/msg01131.txt.bz2 > On Nov 11, 2015, at 7:56 PM, Maxim Kuvyrkov w= rote: >=20 > Hi, >=20 > This patch fixes an obscure cross-testing problem that crashed (OOMed) ou= r boards at Linaro. Several tests in libstdc++ (e.g., [1]) limit themselve= s to some reasonable amount of RAM and then try to allocate 32 gigs. Unfor= tunately, the configure test that checks presence of setrlimit is rather st= range: 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 tar= gets, as if cross-toolchains can't generate working executables. [This is = rather odd, and I might be missing some underlaying caveat.] >=20 > Therefore, when testing a cross toolchain, the test [1] still tries to al= locate 32GB of RAM with no setrlimit restrictions. On most targets that pe= ople 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 imm= ediately fails, or > - the target board has plenty of RAM, so allocating 32GB is not an issue. >=20 > 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 Mus= tang. >=20 > The attached patch removes "native" restriction from configure test for s= etrlimit. This enables setrlimit restrictions on the testsuite, and the te= st [1] expectedly fails to allocate 32GB due to setrlimit restriction. >=20 > 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 [*]. >=20 > OK to commit? >=20 > I didn't go as far as enabling setenv/locale tests when cross-testing lib= stdc++ 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 wa= y that absence of setrlimit does. >=20 > [1] 27_io/ios_base/storage/2.cc >=20 > [*] 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 misbehav= ing only under QEMU. I believe this a QEMU issue with not handling setrlim= it correctly. >=20 Ping. -- Maxim Kuvyrkov www.linaro.org