coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: require_ulimit_v_(): tests skipped with enable-single-binary


From: Dmitry V. Levin
Subject: Re: require_ulimit_v_(): tests skipped with enable-single-binary
Date: Thu, 8 Oct 2015 03:17:58 +0300

On Tue, Sep 22, 2015 at 03:13:54AM +0200, Bernhard Voelker wrote:
> On 09/21/2015 02:56 AM, Pádraig Brady wrote:
> > On 21/09/15 00:47, Bernhard Voelker wrote:
> >> >From 1335ab2713aab020564275c49fdb3e92bb9a207b Mon Sep 17 00:00:00 2001
> >> From: Bernhard Voelker <address@hidden>
> >> Date: Mon, 21 Sep 2015 01:40:33 +0200
> >> Subject: [PATCH] maint: use adaptive approach for `ulimit -v` based tests
> >>
> >> When configured with either 'symlinks' or 'shebangs' as value for
> >> the --enable-single-binary option, tests based on `ulimit -v` are
> >> skipped.  The reason is that the multicall 'coreutils' binary requires
> >> much more memory due to shared libraries being loaded, and the size of
> >> the 'date' binary (~290KiB) compared to the multicall binary (~5MiB),
> >> of course.  Finally, in the case of 'shebangs', the starting shell
> >> requires more memory, too
> >>
> >> Instead of using hard-coded values for the memory limit, use an
> >> adaptive approach: first determine the amount of memory for a similar,
> >> yet more trivial command, and then do the real test run using that
> > 
> > s/command/invocation of the command/
> > 
> > I can't find any significant issues with the patch at all.
> 
> Thanks, I'll push with that change tomorrow.

This approach is very fragile.  It actually failed tests/misc/head-c
on an x86 box with the following diagnostics:

$ (ulimit -v 2048 && src/head -c1 < /dev/null; echo $?)
0
$ (ulimit -v 2048 && src/head --bytes=-2147483647 < /dev/null; echo $?)
src/head: memory exhausted
1
$ (ulimit -v $((2048+128)) && src/head --bytes=-2147483647 < /dev/null; echo $?)
0


-- 
ldv

Attachment: pgppVLwpwI4i8.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]