GNU bug report logs -
#26253
Coreutils 8.26 test failure on arm-linux-gnueabihf
Previous Next
Reported by: ludo <at> gnu.org (Ludovic Courtès)
Date: Sat, 25 Mar 2017 15:46:02 UTC
Severity: important
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#26253: Coreutils 8.26 test failure on arm-linux-gnueabihf
which was filed against the coreutils package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 26253 <at> debbugs.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)]
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 part 3 (message/rfc822, inline)]
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’.
This bug report was last modified 8 years and 52 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.