I'm seeing this same bug. It appears when the process is
connected to a pipe on stdout. Here is my simple test:
$ time -15 4 true
real 0m0.013s
$ time -15 4 true | cat
real 0m4.012s
The problem is that 02-seconds.patch forks a new process which
interferes with signal delivery. The following replacement for
02-seconds.patch uses a better approach of setitimer(), the
high-resolution alternative to alarm().
--- tct-1.18.orig/src/misc/timeout.c 2007-01-11 16:10:29.000000000 -0500
+++ tct-1.18/src/misc/timeout.c 2009-09-10 08:53:09.000000000 -0400
@@ -39,6 +39,8 @@
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
+#include <sys/time.h>
+#include <sys/wait.h>
extern int optind;
@@ -69,10 +71,11 @@ int main(argc, argv)
int argc;
char **argv;
{
- int time_to_run;
+ double time_to_run;
pid_t pid;
pid_t child_pid;
int status;
+ struct itimerval itv;
progname = argv[0];
@@ -83,7 +86,7 @@ char **argv;
if ((kill_signal = atoi(*argv + 1)) <= 0)
usage();
- if (argc < 2 || (time_to_run = atoi(argv[0])) <= 0)
+ if (argc < 2 || (time_to_run = atof(argv[0])) <= 0)
usage();
commandname = argv[1];
@@ -105,7 +108,11 @@ char **argv;
(void) signal(SIGQUIT, terminate);
(void) signal(SIGTERM, terminate);
(void) signal(SIGALRM, terminate);
- alarm(time_to_run);
+ itv.it_value.tv_sec = (long)time_to_run;
+ itv.it_value.tv_usec = (time_to_run-itv.it_value.tv_sec)*1000000;
+ itv.it_interval.tv_sec = 0;
+ itv.it_interval.tv_usec = 0;
+ (void) setitimer(ITIMER_REAL, &itv, NULL);
while ((pid = wait(&status)) != -1 && pid != child_pid)
/* void */ ;
return (pid == child_pid ? WEXITSTATUS(status) | WTERMSIG(status) : -1);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
