[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bernhard Voelker
Subject: bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x
Date: Fri, 19 Sep 2014 10:36:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

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
+ 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.
==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== 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== For counts of detected and suppressed errors, rerun with: -v
==10209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+ test 1 -lt 1
++ grep '^[0-9][0-9]*$' out_1_1
++ sort -un
++ wc -l
++ wc -l
+ 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.


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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]