bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
tags 8846 + moreinfo
thanks
Bruno Haible wrote:
Jim Meyering wrote:
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -74,7 +74,7 @@ Exit () { set +e; (exit $1); exit $1; }
# the reason for skip/failure to console, rather than to the .log files.
: ${stderr_fileno_=2}
-warn_ () { echo $@ 1$stderr_fileno_; }
+warn_ () { eval 'echo $@ 1'$stderr_fileno_; }
fail_ () { warn_ $ME_: failed test: $@; Exit 1; }
skip_ () { warn_ $ME_: skipped test: $@; Exit 77; }
framework_failure_ () { warn_ $ME_: set-up failure: $@; Exit 99; }
After applying this patch, here's the test-suite.log that I now get.
Hi Bruno,
This turned into a long thread.
I think all issues raised here have been resolved.
Can you confirm?
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
Hi Jim, I think all issues raised here have been resolved. Can you confirm? I think the du/inaccessible-cwd failure was not tackled. But anyway, feel free to close it, and let's test again when you have a pre-release of coreutils-8.13 that you want to get tested. Bruno -- In memoriam Szczepan Ścibior http://pl.wikipedia.org/wiki/Szczepan_Ścibior http://home.clara.net/clinchy/neeb5.htm
bug#6768: ls: fix a test failure that should have been skipped
Eric Blake wrote: On 07/30/2010 07:49 PM, d...@linux.ucla.edu wrote: Hi, I just ran into this one test failure while building the latest sources. The test didn't really fail, but the exit via the function invoked in $() doesn't terminate the test script, it simply terminates the substitution command. Here are the bits where it failed: ++ case $base in ++ skip_test_ 'mount point component starts with .' ... ++ exit 77 + readdir_inode= ++ env stat --format=%i /home/dsh/.gvfs Thanks; applied. Subject: [PATCH] ls: fix a test failure that should have been skipped Thanks. Closing this issue.
bug#6900: mktemp: want option to make a fifo
forcemerge 6900 6330 tags 6900 notabug close 6900 thanks Eric Blake wrote: On 08/23/2010 09:22 AM, John Reiser wrote: mktemp: Please add an option which creates a fifo instead of a file or a directory. --fifo seems appropriate, although the abbreviation -f might be confused as a request for an ordinary file; and -p as in --pipe is already taken for prefix. Thanks for the report. However, I'm inclined to mark this bug as a duplicate of 6330, for the reasons already documented in this long thread: http://lists.gnu.org/archive/html/bug-coreutils/2010-06/msg00013.html I've just merged them and closed both. It's clear that the proposed change is neithehr required nor justified.
bug#6936: Bug#594666: /usr/bin/tac: tac aborts
Jim Meyering wrote: Salvo Tomaselli wrote: Package: coreutils Version: 8.5-1 Severity: normal File: /usr/bin/tac Tac aborts when using it on a particular file. *** glibc detected *** tac: double free or corruption (top): 0x025c5030 *** ... Thank you for the report! That is indeed a bug in the very latest. For a stand-alone, minimal demonstrator, run this: valgrind tac (printf %0$((2**14 + 1))d 0) /dev/null It prints this: Invalid free() / delete / delete[] at 0x4A04D72: free (vg_replace_malloc.c:325) by 0x402294: main (tac.c:669) Address 0x4c30040 is 0 bytes inside a block of size 16,388 free'd at 0x4A05255: realloc (vg_replace_malloc.c:476) by 0x4117B8: xrealloc (xmalloc.c:57) by 0x401A68: tac_seekable (tac.c:319) by 0x402379: main (tac.c:515) Here is a fix: From b3959fc691e606857a3c6e9b316ec34819972245 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sat, 28 Aug 2010 17:45:29 +0200 Subject: [PATCH] tac: avoid double free * src/tac.c (main): Reading a line longer than 16KiB would cause tac to realloc its primary buffer. Then, just before exit, tac would mistakenly free the original (now free'd) buffer. This bug was introduced by commit be6c13e7, maint: always free a buffer, to avoid even semblance of a leak. * NEWS (Bug fixes): Mention it. * tests/misc/tac (double-free): New test, to exercise this. Reported by Salvo Tomaselli in http://bugs.debian.org/594666. This was fixed long ago. Marking as done.
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
Bruno Haible wrote:
Hi Jim,
I think all issues raised here have been resolved.
Can you confirm?
I think the du/inaccessible-cwd failure was not tackled. But anyway, feel
free to close it, and let's test again when you have a pre-release of
coreutils-8.13 that you want to get tested.
Thanks.
I think that failure is inevitable on any system with
such poor (save-cwd/restore-cwd--based) openat emulation.
I.e., since it has neither the *at functions nor the
/proc-based support to emulate them, the test must fail.
If only to forestall further bug reports, it'd be good to
arrange to skip that test on such systems.
From 24a047d93db642b8e73122a6e6553a475f216572 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 7 Aug 2011 22:09:42 +0200
Subject: [PATCH] tests: avoid lack-of-support du test failure on HP-UX 11.31
* tests/du/inaccessible-cwd: Skip this test on systems like HP-UX 11.31
that lack both the *at functions and the /proc/self/fd-based support
we might have used to emulate them. Reported by Bruno Haible in
http://debbugs.gnu.org/8846
---
tests/du/inaccessible-cwd |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tests/du/inaccessible-cwd b/tests/du/inaccessible-cwd
index 220ac7b..3dfe601 100755
--- a/tests/du/inaccessible-cwd
+++ b/tests/du/inaccessible-cwd
@@ -22,6 +22,11 @@
. ${srcdir=.}/init.sh; path_prepend_ ../src
print_ver_ du
+
+# Skip this test if your system has neither the openat-style functions
+# nor /proc/self/fd support with which to emulate them.
+require_openat_support_
+
skip_if_root_
cwd=`pwd`
--
1.7.4.4
bug#7182: sort -R slow
Davide Brini wrote:
On Sat, 9 Oct 2010 14:52:41 +0200 Ole Tange ta...@gnu.org wrote:
I recently needed to randomize some lines. So I tried using 'sort -R'.
I was astonished how slow that was. So I tested how slow a competing
strategies are. GNU sort is two magnitudes slower than unsort and more
than one magnitude slower than perl:
$ time unsort file
real0m1.388s
$ unsort --version
unsort 1.1.2
$ time perl -e 'print sort { rand() = rand() } ' file
real0m6.621s
$ time sort -R file
real4m8.403s
$ sort --version
sort (GNU coreutils) 8.5
What is even scarier: sort without -R is faster than sort -R:
$ time sort file
real0m53.553s
I would expect sort -R to be faster than sort and faster than Perl if
not as fast as unsort.
On my system, locale settings seem to impact the runtime significantly:
$ wc -l bigfile
100 bigfile
$ time LC_ALL=en_US.utf8 sort -R bigfile /dev/null
real 1m29.302s
user 1m21.009s
sys 0m0.155s
$ time LC_ALL=C sort -R bigfile /dev/null
real 0m38.881s
user 0m35.276s
sys 0m0.118s
However, shuf is much faster, and seems mostly unaffected by the locale
used:
$ time shuf bigfile /dev/null
real 0m1.044s
user 0m0.833s
sys 0m0.042s
Thanks for the report.
I think the performance of sort -R will often be worse
than that of shuf (by design, since it accesses each byte of each line
once more, to compute the hash), except when the input size is larger
than available memory.
The info documentation for sort -R does refer to shuf.
Any suggestions for improvements are welcome.
I'm closing this.
You're welcome to reopen or file a new report.
