public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: Mike Stump <mikestump@comcast.net>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	libstdc++ <libstdc++@gcc.gnu.org>
Subject: Re: [PATCH] Fix detection of setrlimit in libstdc++ testsuite
Date: Wed, 31 Aug 2016 11:22:00 -0000	[thread overview]
Message-ID: <AE7F1556-596F-44C9-9707-0EA9CE975F13@linaro.org> (raw)
In-Reply-To: <20160405112032.GF5814@redhat.com>

> 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



  reply	other threads:[~2016-08-31 11:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-11 16:56 Maxim Kuvyrkov
2015-12-10 13:48 ` Maxim Kuvyrkov
2016-03-02 10:08   ` Maxim Kuvyrkov
2016-03-02 17:38     ` Mike Stump
2016-03-04 15:27       ` Jonathan Wakely
2016-04-05 11:20       ` Jonathan Wakely
2016-08-31 11:22         ` Maxim Kuvyrkov [this message]
2016-08-31 13:23           ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AE7F1556-596F-44C9-9707-0EA9CE975F13@linaro.org \
    --to=maxim.kuvyrkov@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=mikestump@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).