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

[Pádraig Brady]

tag 18500 notabug
close 18500
stop

On 09/18/2014 02:33 PM, Philipp Thomas wrote:
> The testsuite of coreutils 8.22 is failing on s390. Can anybody help me
> pinpointing the culprit?
>
> Here is the relevant part of the log:
>
> 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-missing.html

The patch in this case seems simple?
https://bugs.kde.org/show_bug.cgi?id=331337

thanks,
Pádraig.