GNU bug report logs - #18500
shuf-reservoir from coreutils 8.22 failing on s390x

Previous Next

Full log

View this message in rfc822 format

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,  Philipp Thomas <pth <at> suse.de>
Cc: 18500 <at> debbugs.gnu.org
Subject: bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x
Date: Fri, 19 Sep 2014 10:36:30 +0200

On 09/19/2014 02:59 AM, Pádraig Brady wrote:
>> FAIL: tests/misc/shuf-reservoir
>> ===============================
>
>> + valgrind --leak-check=summary --error-exitcode=1 shuf -n 1 -o out_1_1
>> ==10209== Memcheck, a memory error detector
>> ==10209== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
>> ==10209== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
>> ==10209== Command: shuf -n 1 -o out_1_1
>> ==10209==
>> + seq 1
>> --10209-- WARNING: unhandled syscall: 326
>> --10209-- You may be able to write your own handler.
>> --10209-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
>> --10209-- Nevertheless we consider this a bug.  Please report
>> --10209-- it at http://valgrind.org/support/bug_reports.html.
>> 1
>> ==10209==
>> ==10209== HEAP SUMMARY:
>> ==10209==     in use at exit: 37,112 bytes in 5 blocks
>> ==10209==   total heap usage: 8 allocs, 3 frees, 37,188 bytes allocated
>> ==10209==
>> ==10209== LEAK SUMMARY:
>> ==10209==    definitely lost: 32,832 bytes in 3 blocks
>> ==10209==    indirectly lost: 4,280 bytes in 2 blocks
>> ==10209==      possibly lost: 0 bytes in 0 blocks
>> ==10209==    still reachable: 0 bytes in 0 blocks
>> ==10209==         suppressed: 0 bytes in 0 blocks
>> ==10209== Rerun with --leak-check=full to see details of leaked memory
>> ==10209==
>> ==10209== For counts of detected and suppressed errors, rerun with: -v
>> ==10209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>> + EXPECTED_LINES=1
>> + test 1 -lt 1
>> ++ grep '^[0-9][0-9]*$' out_1_1
>> ++ sort -un
>> ++ wc -l
>> + GOOD_LINES=0
>> ++ wc -l
>> + LINES=0
>> + test 1 -eq 0
>> + return 1
>> + fail=1
>> + echo 'shuf-reservoir-sampling failed with IN_N=1 OUT_N=1'
>> shuf-reservoir-sampling failed with IN_N=1 OUT_N=1
>>
> It seems to be a limitation of the valgrind implementation on your system,
> which is causing valgrind to bail out without shuf outputting anything?
> I could put an explicit check for that and skip in the test,
> however it would be best to avoid that by fixing valgrind instead.
>
> http://valgrind.org/docs/manual/dist.readme

IMO there's something weird additionally going on here:

If valgrind doesn't work, then it should exit non-Zero.
As it doesn't, I assume it runs shuf(1). As shuf(1) creates
the output file itself via the -o option, this is the proof
the it has really run (and wc(1) would complain otherwise).

BUT: all invocations in the log output lead to LINES=0!
That would mean that 'shuf -n' really is not working on s390x,
it always produces an empty file.

@Philipp: can you confirm please? I don't have access to
such a s390x machine ...

Have a nice day,
Berny

Previous Next

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