[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x
From: |
Pádraig Brady |
Subject: |
bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x |
Date: |
Fri, 19 Sep 2014 01:59:36 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
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.
- bug#18500: shuf-reservoir from coreutils 8.22 failing on s390x,
Pádraig Brady <=