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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#26253: closed (Coreutils 8.26 test failure on arm-linux-gnueabihf)
Date: Tue, 28 Mar 2017 04:31:02 +0000

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

Your message dated Mon, 27 Mar 2017 21:30:09 -0700
with message-id <9fb386eb-96f2-5041-827b-9a5739e72aee <at> draigBrady.com>
and subject line Re: bug#26253: tests/misc/cut-huge-range.sh fails on arm-linux-gnueabihf
has caused the debbugs.gnu.org bug report #26253,
regarding Coreutils 8.26 test failure on arm-linux-gnueabihf
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
26253: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26253
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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 part 3 (message/rfc822, inline)]

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

Previous Next

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