GNU bug report logs - #26253
Coreutils 8.26 test failure on arm-linux-gnueabihf

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26253 in the body.
You can then email your comments to 26253 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-guix <at> gnu.org
Subject: Coreutils 8.26 test failure on arm-linux-gnueabihf
Date: Sat, 25 Mar 2017 16:45:33 +0100

In current ‘core-updates’ (7fdca77e007f0838ecd32b044827678f2b345ff0),
tests/misc/cut-huge-range.sh in Coreutils 8.26 fails reproducibly in the
chroot build environment; it succeeds outside of it.

When it fails, cut-huge-range.log shows this:

--8<---------------cut here---------------start------------->8---
+ CUT_MAX=4294967294
+ ulimit -v 3004
+ cut -b4294967294- /dev/null
+ ulimit -v 3004
+ cut -b1-4294967294 /dev/null
+ ulimit -v 3004
+ returns_ 1 cut -b4294967295 /dev/null
+ fail=1
+ ulimit -v 3004
+ returns_ 1 cut -b4294967296 /dev/null
+ fail=1
+ compare /dev/null err
+ compare_dev_null_ /dev/null err
+ test 2 = 2
+ test x/dev/null = x/dev/null
+ test -s err
+ return 0
+ return 0
+ Exit 1
--8<---------------cut here---------------end--------------->8---

So the two lines that fail are these:

--8<---------------cut here---------------start------------->8---
# Explicitly disallow values above CUT_MAX
(ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || fail=1
(ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || fail=1
--8<---------------cut here---------------end--------------->8---

I don’t understand why at this point, but I found that removing
“2>/dev/null” from these two lines lets the test pass (and AIUI, this
redirection is not necessary for the test; it just hides the

  cut: byte/character offset '4294967296' is too large
  
error message.)

I’ve tried to reduce the test case to facilitate debugging, to no
avail.

To be continued!

Ludo’.

Message #8 received at 26253 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 26253 <at> debbugs.gnu.org
Subject: Re: bug#26253: Coreutils 8.26 test failure on arm-linux-gnueabihf
Date: Sat, 25 Mar 2017 14:18:50 -0400

On Sat, Mar 25, 2017 at 04:45:33PM +0100, Ludovic Courtès wrote:
> In current ‘core-updates’ (7fdca77e007f0838ecd32b044827678f2b345ff0),
> tests/misc/cut-huge-range.sh in Coreutils 8.26 fails reproducibly in the
> chroot build environment; it succeeds outside of it.

[...]

> So the two lines that fail are these:
> 
> --8<---------------cut here---------------start------------->8---
> # Explicitly disallow values above CUT_MAX
> (ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || fail=1
> (ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || fail=1
> --8<---------------cut here---------------end--------------->8---
> 
> I don’t understand why at this point, but I found that removing
> “2>/dev/null” from these two lines lets the test pass (and AIUI, this
> redirection is not necessary for the test; it just hides the

Is the same Bash shared between these two test environments (inside and
outside of the chroot)?

Message #11 received at 26253 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Leo Famulari <leo <at> famulari.name>
Cc: 26253 <at> debbugs.gnu.org
Subject: Re: bug#26253: Coreutils 8.26 test failure on arm-linux-gnueabihf
Date: Sat, 25 Mar 2017 22:30:51 +0100

Leo Famulari <leo <at> famulari.name> skribis:

> On Sat, Mar 25, 2017 at 04:45:33PM +0100, Ludovic Courtès wrote:
>> In current ‘core-updates’ (7fdca77e007f0838ecd32b044827678f2b345ff0),
>> tests/misc/cut-huge-range.sh in Coreutils 8.26 fails reproducibly in the
>> chroot build environment; it succeeds outside of it.
>
> [...]
>
>> So the two lines that fail are these:
>> 
>> --8<---------------cut here---------------start------------->8---
>> # Explicitly disallow values above CUT_MAX
>> (ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || fail=1
>> (ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || fail=1
>> --8<---------------cut here---------------end--------------->8---
>> 
>> I don’t understand why at this point, but I found that removing
>> “2>/dev/null” from these two lines lets the test pass (and AIUI, this
>> redirection is not necessary for the test; it just hides the
>
> Is the same Bash shared between these two test environments (inside and
> outside of the chroot)?

Yes.  For the outside test, I just did “guix build -K” and then “source
environment-variables”, which should give me the right $SHELL and so on.

Ludo’.

Message #16 received at 26253 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: 26253 <at> debbugs.gnu.org
Subject: Re: bug#26253: Coreutils 8.26 test failure on arm-linux-gnueabihf
Date: Sat, 25 Mar 2017 23:08:31 +0100

[Message part 1 (text/plain, inline)]

ludo <at> gnu.org (Ludovic Courtès) skribis:

> So the two lines that fail are these:
>
> # Explicitly disallow values above CUT_MAX
> (ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || fail=1
> (ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || fail=1
>
> I don’t understand why at this point, but I found that removing
> “2>/dev/null” from these two lines lets the test pass (and AIUI, this
> redirection is not necessary for the test; it just hides the
>
>   cut: byte/character offset '4294967296' is too large
>   
> error message.)

With the attached file I (and a patch coreutils such that it would
build; #:tests? #f is enough), I was able to reproduce the problem.  The
build log I get is this:

--8<---------------cut here---------------start------------->8---
+ ulimit -v 2004
+ echo before
before
+ /gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut -b4294967296 /dev/null
/gnu/store/9bkl74hd3f1gysdkq22hp8w4z9w8022l-bash-4.4.12/bin/sh: xmalloc: variables.c:4539: cannot allocate 69 bytes (57344 bytes allocated)
+ echo after 2
after 2
/gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut: byte/character offset '4294967296' is too large
Try '/gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut --help' for more information.
/gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut: byte/character offset '4294967296' is too large
Try '/gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut --help' for more information.

;;; (bash "/gnu/store/9bkl74hd3f1gysdkq22hp8w4z9w8022l-bash-4.4.12/bin/sh")

;;; (status 0 0)

;;; (status2 256 1)

;;; (status3 256 1)
--8<---------------cut here---------------end--------------->8---

The thing that’s failing here is the shell that invokes ‘cut’, and thus
we get an exit value of 2 whereas the test explicitly checks for 1.

This is very sensitive: depending on the command sequence we pass to “sh
-c”, we hit that problem or we don’t.  The fact that removing
“2>/dev/null”  solved the problem was probably just chance.

So I think Coreutils commit 28803c8a3144d5d4363cdbd148bbe067af1a67c2,
which arbitrarily increased the value passed to “ulimit -v”, goes in the
right direction after all but is insufficient.

I’m trying out a new patch based on that and will push if it works.

Ludo’.

[test-coreutils.scm (text/plain, inline)]

(use-modules (guix))

(define cu (@@ (gnu packages commencement) coreutils-final))
(define bash (@@ (gnu packages commencement) bash-final))

(define build
  #~(let* ((_ #$output)
           (cut (string-append #$cu "/bin/cut -b4294967296 /dev/null "))
           (status (system* (pk 'bash (string-append #$bash "/bin/sh")) "-c"
                            (string-append "set -x; (ulimit -v 2004; echo before; "
                                           cut " 2>/dev/null)"
                                           "; echo after $?")))
           (status2 (system cut))
           (status3 (apply system* (string-tokenize cut))))
      (pk 'status status (status:exit-val status))
      (pk 'status2 status2 (status:exit-val status2))
      (pk 'status3 status3 (status:exit-val status3))
      #f))

(with-store store
  (run-with-store store
    (mlet %store-monad ((drv (gexp->derivation "foo" build)))
      (built-derivations (list drv)))))

Message #19 received at 26253 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: 26253 <at> debbugs.gnu.org
Subject: Re: bug#26253: Coreutils 8.26 test failure on arm-linux-gnueabihf
Date: Sat, 25 Mar 2017 23:33:33 +0100

I just pushed a fix:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=d1e3f59c9b8d1be79eded04fe23cceb56b4372f0

Ludo’.

Message #24 received at 26253 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 26253 <at> debbugs.gnu.org
Subject: tests/misc/cut-huge-range.sh fails on arm-linux-gnueabihf
Date: Sun, 26 Mar 2017 15:41:23 +0200

Hi Pádraig,

We found that ‘tests/misc/cut-huge-range.sh’ would fail on our ARMv7
GNU/Linux machines:

  https://bugs.gnu.org/26253

(I noticed there’s a thinko in the patch I used for Guix: ‘getconf
PAGESIZE’ returns bytes whereas ‘ulimit -v’ expects kibibytes).

The reason for this failure is that the limit passed to ‘ulimit -v’
would be slightly too low, even after Coreutils commit
28803c8a3144d5d4363cdbd148bbe067af1a67c2 (2004 KiB before and 3004KiB
after this commit.)

Part of the reason, I think, is that ‘vm’ is computed by simply running
‘cut -b1’:

  vm=$(get_min_ulimit_v_ cut -b1 /dev/null) \
    || skip_ "this shell lacks ulimit support"

… but the last couple of tests also run sh within that limit:

  # Explicitly disallow values above CUT_MAX
  (ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || fail=1
  (ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || fail=1

It might be more accurate to do something like:

  vm=$(get_min_ulimit_v_ sh -c 'cut -b1 /dev/null')

However it still seems easy to slightly underestimate the limit and get
those spurious failures.

Thoughts?

Ludo’.

Message #27 received at 26253 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 26253 <at> debbugs.gnu.org
Subject: Re: bug#26253: Coreutils 8.26 test failure on arm-linux-gnueabihf
Date: Sun, 26 Mar 2017 15:15:00 -0400

On Sat, Mar 25, 2017 at 11:33:33PM +0100, Ludovic Courtès wrote:
> I just pushed a fix:
> 
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=d1e3f59c9b8d1be79eded04fe23cceb56b4372f0

Thank you for your persistent debugging!

Message #30 received at 26253 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 26253 <at> debbugs.gnu.org
Subject: Re: bug#26253: tests/misc/cut-huge-range.sh fails on
 arm-linux-gnueabihf
Date: Sun, 26 Mar 2017 15:52:30 -0700

On 26/03/17 06:41, Ludovic Courtès wrote:
> Hi Pádraig,
> 
> We found that ‘tests/misc/cut-huge-range.sh’ would fail on our ARMv7
> GNU/Linux machines:
> 
>   https://bugs.gnu.org/26253
> 
> (I noticed there’s a thinko in the patch I used for Guix: ‘getconf
> PAGESIZE’ returns bytes whereas ‘ulimit -v’ expects kibibytes).
> 
> The reason for this failure is that the limit passed to ‘ulimit -v’
> would be slightly too low, even after Coreutils commit
> 28803c8a3144d5d4363cdbd148bbe067af1a67c2 (2004 KiB before and 3004KiB
> after this commit.)
> 
> Part of the reason, I think, is that ‘vm’ is computed by simply running
> ‘cut -b1’:
> 
>   vm=$(get_min_ulimit_v_ cut -b1 /dev/null) \
>     || skip_ "this shell lacks ulimit support"
> 
> … but the last couple of tests also run sh within that limit:

Are you saying the returns_ call induces a subshell?
I suppose it might on some shells, though it doesn't seem to on bash 4.3 here.

> 
>   # Explicitly disallow values above CUT_MAX
>   (ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || fail=1
>   (ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || fail=1
> 
> It might be more accurate to do something like:
> 
>   vm=$(get_min_ulimit_v_ sh -c 'cut -b1 /dev/null')

That give 10004 rather than 5004 on my x86_64 system here.
Another option might be to use:
  vm=$(get_min_ulimit_v_ returns_ 0 cut -b1 /dev/null)

Does that give better results for you?

> However it still seems easy to slightly underestimate the limit and get
> those spurious failures.
> 
> Thoughts?

We've bumped these limits up by fixed amounts in some cases,
so if we don't get a more general solution I'll apply your
patch to coreutils upstream, replacing `getconf PAGESIZE` with 4096.

cheers,
Pádraig

Message #33 received at 26253 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 26253 <at> debbugs.gnu.org
Subject: Re: bug#26253: tests/misc/cut-huge-range.sh fails on
 arm-linux-gnueabihf
Date: Mon, 27 Mar 2017 11:18:54 +0200

[Message part 1 (text/plain, inline)]

Hi Pádraig,

Pádraig Brady <P <at> draigBrady.com> skribis:

> On 26/03/17 06:41, Ludovic Courtès wrote:

[...]

>> Part of the reason, I think, is that ‘vm’ is computed by simply running
>> ‘cut -b1’:
>> 
>>   vm=$(get_min_ulimit_v_ cut -b1 /dev/null) \
>>     || skip_ "this shell lacks ulimit support"
>> 
>> … but the last couple of tests also run sh within that limit:
>
> Are you saying the returns_ call induces a subshell?
> I suppose it might on some shells, though it doesn't seem to on bash 4.3 here.

I don’t think ‘return_’ spawns a subshell, but the ulimit should account
for memory needed by the shell in addition to what ‘cut’ needs.

>>   # Explicitly disallow values above CUT_MAX
>>   (ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || fail=1
>>   (ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || fail=1
>> 
>> It might be more accurate to do something like:
>> 
>>   vm=$(get_min_ulimit_v_ sh -c 'cut -b1 /dev/null')
>
> That give 10004 rather than 5004 on my x86_64 system here.
> Another option might be to use:
>   vm=$(get_min_ulimit_v_ returns_ 0 cut -b1 /dev/null)
>
> Does that give better results for you?

Yes the patch below on top of 8.26 (that is, without vm += 1000) works
for me.

Thanks,
Ludo’.

[Message part 2 (text/x-patch, inline)]

diff --git a/tests/misc/cut-huge-range.sh b/tests/misc/cut-huge-range.sh
index 6b3c5b6ed..eeba33fce 100755
--- a/tests/misc/cut-huge-range.sh
+++ b/tests/misc/cut-huge-range.sh
@@ -20,7 +20,7 @@
 print_ver_ cut
 getlimits_
 
-vm=$(get_min_ulimit_v_ cut -b1 /dev/null) \
+vm=$(get_min_ulimit_v_ returns_ 0 cut -b1 /dev/null) \
   || skip_ "this shell lacks ulimit support"

Message #38 received at 26253-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 26253-done <at> debbugs.gnu.org
Subject: Re: bug#26253: tests/misc/cut-huge-range.sh fails on
 arm-linux-gnueabihf
Date: Mon, 27 Mar 2017 21:30:09 -0700

On 27/03/17 02:18, Ludovic Courtès wrote:
> Hi Pádraig,
> 
> Pádraig Brady <P <at> draigBrady.com> skribis:
> 
>> On 26/03/17 06:41, Ludovic Courtès wrote:
> 
> [...]
> 
>>> Part of the reason, I think, is that ‘vm’ is computed by simply running
>>> ‘cut -b1’:
>>>
>>>   vm=$(get_min_ulimit_v_ cut -b1 /dev/null) \
>>>     || skip_ "this shell lacks ulimit support"
>>>
>>> … but the last couple of tests also run sh within that limit:
>>
>> Are you saying the returns_ call induces a subshell?
>> I suppose it might on some shells, though it doesn't seem to on bash 4.3 here.
> 
> I don’t think ‘return_’ spawns a subshell, but the ulimit should account
> for memory needed by the shell in addition to what ‘cut’ needs.
> 
>>>   # Explicitly disallow values above CUT_MAX
>>>   (ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || fail=1
>>>   (ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || fail=1
>>>
>>> It might be more accurate to do something like:
>>>
>>>   vm=$(get_min_ulimit_v_ sh -c 'cut -b1 /dev/null')
>>
>> That give 10004 rather than 5004 on my x86_64 system here.
>> Another option might be to use:
>>   vm=$(get_min_ulimit_v_ returns_ 0 cut -b1 /dev/null)
>>
>> Does that give better results for you?
> 
> Yes the patch below on top of 8.26 (that is, without vm += 1000) works
> for me.
> 
> Thanks,
> Ludo’.

Pushed in your name at:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=f542200

Marking this as done.

cheers,
Pádraig

Message #41 received at 26253-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 26253-done <at> debbugs.gnu.org
Subject: Re: bug#26253: tests/misc/cut-huge-range.sh fails on
 arm-linux-gnueabihf
Date: Tue, 28 Mar 2017 10:18:42 +0200

Pádraig Brady <P <at> draigBrady.com> skribis:

> Pushed in your name at:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=f542200

Thank you!

Ludo'.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.