bug-coreutils
[Top][All Lists]
Advanced

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

bug#13185: Test case 'misc/timeout-group' failed


From: Pádraig Brady
Subject: bug#13185: Test case 'misc/timeout-group' failed
Date: Tue, 18 Dec 2012 13:18:26 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 12/18/2012 09:45 AM, Stefano Lattarini wrote:
On 12/18/2012 01:48 AM, Pádraig Brady wrote:

So the skip was on purpose and to avoid signal propagation issues seen
on some older systems:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=v8.14-30-g6603e37

This initial failure is worrying, though may be a false positive
due to your shell or something. What versions of dash, bash, kernel
do you have there?


   $ bash --version
   GNU bash, version 4.2.36(2)-release (i686-pc-linux-gnu)

   $ dpkg -l dash | sed -n '$p'
   ii  dash  0.5.7-3  i386  POSIX-compliant shell

   $ uname -rsv
   Linux 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009

I can't reproduce at all here with any shell, though you might
have older versions.

What is your system /bin/sh, dash or bash?

Bash.  But the affected coreutils testsuite run was done with a
more bleeding-edge version of bash, explicitly selected as SHELL
(and CONFIG_SHELL).

Note you can force a particular SHELL as follows,
and it would be interesting to see if the issue affected all shells.

The fact is that I haven't been able to reproduce the issue after
the first failure.  So it won't be easy to ensure whether it has
been fixed...

make check TESTS='tests/misc/timeout-group.sh' SUBDIRS=. VERBOSE=yes SHELL=bash

Hopefully we can come up with a skip for this case too.

I noticed a possible race in the test script.
So I'll apply this soon.

thanks,
Pádraig.

commit 09f72d285514a91495960ea3b0570251eed415b0
Author: Pádraig Brady <address@hidden>
Date:   Tue Dec 18 13:06:15 2012 +0000

    tests: avoid a race in timeout-group.sh

    * tests/misc/timeout-group.sh: The kernel might possibly delay
    signal propagation to timeout.cmd long enough, that it exits
    normally without running the signal handler (as sleep will
    be in the same process group and so get the signal too).
    So avoid this by explicitly checking that the signal handler
    is called, which should always happen under normal circumstances.
    Reported by Stefano Lattarini on linux-2.6.30-2-686 and bash-4.2.36.

diff --git a/tests/misc/timeout-group.sh b/tests/misc/timeout-group.sh
index 4cefc33..7117abb 100755
--- a/tests/misc/timeout-group.sh
+++ b/tests/misc/timeout-group.sh
@@ -34,7 +34,11 @@ cat > timeout.cmd <<\EOF
 #!/bin/sh
 trap 'touch int.received; exit' INT
 touch timeout.running
-sleep $1
+count=$1
+until test -e int.received || test $count = 0; do
+  sleep 1
+  count=$(expr $count - 1)
+done
 EOF
 chmod a+x timeout.cmd








reply via email to

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