bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x

[Bernhard Voelker]

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