Subject: bug#9737: closed (Re: bug#9737: misc/timeout-group: spurious test failure on SLES 10.3 (coreutils 8.14))

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 13 Oct 2011 14:10:02 +0000

Your bug report

#9737: misc/timeout-group: spurious test failure on SLES 10.3  (coreutils 8.14)

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
9737: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9737
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#9737: misc/timeout-group: spurious test failure on SLES 10.3 (coreutils 8.14)
From: Pádraig Brady <[email-masked]>
To: "Voelker, Bernhard" <[email-masked]>
Cc: [email-masked]
Date: Thu, 13 Oct 2011 15:08:43 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

On 10/12/2011 03:05 PM, Voelker, Bernhard wrote:
> I don't wanna ruin your day (by reporting on 0-day old 8.14), but ...
> 
> On a virtual SLES 10.3 system with 2 Xeons (E5420  @ 2.50GHz),
> the above test failed - but just once.
> 
> I cannot reproduce the error. I tried ~30 times, once with low system
> load and once with a load of about 10.
> 
> Fortunately, I saved the logfile before retrying.
> Ideas?
> 
> Berny

Bah, this is just a racy test I think.
Hopefully the attached fixes it.

cheers,
Pádraig.
>From de893d537dab5ab1ed2f61ee81c18603b52784d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= <[email-masked]>
Date: Thu, 13 Oct 2011 14:58:58 +0100
Subject: [PATCH] tests: fix a race in timeout-group

This could cause a false failure, or even
an infinite loop in rare circumstances.

* tests/misc/timeout-group: Increase the timeouts
passed to the timeout command, so that they're
effectively not used.  Instead the command termination
is triggered by the kill commands when everything
is in the correct state.

Reported by Bernhard Voelker.
---
 tests/misc/timeout-group |   20 +++++++++++++++-----
 1 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/tests/misc/timeout-group b/tests/misc/timeout-group
index fedd53a..1ad2a87 100755
--- a/tests/misc/timeout-group
+++ b/tests/misc/timeout-group
@@ -40,15 +40,24 @@ chmod a+x timeout.cmd
 
 cat > group.sh <<\EOF
 #!/bin/sh
-timeout --foreground 5 ./timeout.cmd 10&
+timeout --foreground 25 ./timeout.cmd 20&
 wait
 EOF
 chmod a+x group.sh
 
+check_timeout_cmd_running()
+{
+  local delay="$1"
+  test -e timeout.running ||
+    { sleep $delay; return 1; }
+}
+
+
 # Start above script in its own group.
 # We could use timeout for this, but that assumes an implementation.
 setsid ./group.sh &
-until test -e timeout.running; do sleep .1; done
+# Wait 6.3s for timeout.cmd to start
+retry_delay_ check_timeout_cmd_running .1 6 || fail=1
 # Simulate a Ctrl-C to the group to test timely exit
 # Note dash doesn't support signalling groups (a leading -)
 env kill -INT -- -$!
@@ -66,9 +75,10 @@ rm -f int.received timeout.running
 # Note the first timeout must send a signal that
 # the second is handling for it to be propagated to the command.
 # SIGINT, SIGTERM, SIGALRM etc. are implicit.
-timeout -sALRM 2 timeout -sINT 10 ./timeout.cmd 5&
-until test -e timeout.running; do sleep .1; done
-kill -ALRM $!
+timeout -sALRM 30 timeout -sINT 25 ./timeout.cmd 20&
+# Wait 6.3s for timeout.cmd to start
+retry_delay_ check_timeout_cmd_running .1 6 || fail=1
+kill -ALRM $! # trigger the alarm of the first timeout command
 wait
 test -e int.received || fail=1
 
-- 
1.7.6

Subject: misc/timeout-group: spurious test failure on SLES 10.3 (coreutils 8.14)
From: "Voelker, Bernhard" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 12 Oct 2011 16:05:10 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

I don't wanna ruin your day (by reporting on 0-day old 8.14), but ...

On a virtual SLES 10.3 system with 2 Xeons (E5420  @ 2.50GHz),
the above test failed - but just once.

I cannot reproduce the error. I tried ~30 times, once with low system
load and once with a load of about 10.

Fortunately, I saved the logfile before retrying.
Ideas?

Berny