GNU bug report logs - #8938
make timeout and CTRL-C

Previous Next

Full log

Message #83 received at 8938 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 8938 <at> debbugs.gnu.org
Subject: Re: bug#8938: make timeout and CTRL-C
Date: Thu, 07 Jul 2011 13:13:52 +0200

Pádraig Brady wrote:

> On 07/07/11 11:05, Pádraig Brady wrote:
>> On 06/07/11 23:37, Pádraig Brady wrote:
>>> OK I've added --foreground to support this.
>>> Note it still maintains a separate timeout
>>> monitor process to return 124 on timeout etc.
>>
>> Updated wording and NEWS entry now included.
>> I'll push this later today.
>
> I'm also thinking of pushing this as a separate patch,
> which will set WIFSIGNALED for the timeout process itself.
> This will make timeout more transparent and when doing
> Ctrl-C from make for example, printing "[target] Interrupt"
> rather than "[target] Error 130".
>
> diff --git a/src/timeout.c b/src/timeout.c
> index a686225..ea4af18 100644
> --- a/src/timeout.c
> +++ b/src/timeout.c
> @@ -341,7 +361,19 @@ main (int argc, char **argv)
>            if (WIFEXITED (status))
>              status = WEXITSTATUS (status);
>            else if (WIFSIGNALED (status))
> -            status = WTERMSIG (status) + 128; /* what sh does at least.  */
> +            {
> +              int sig = WTERMSIG (status);
> +              if (!timed_out)
> +                {
> +                  /* exit with the signal flag set, but avoid core files.  */
> +                  if (setrlimit (RLIMIT_CORE, &(struct rlimit) {0,0}) == 0)
> +                    {
> +                      signal (sig, SIG_DFL);
> +                      raise (sig);
> +                    }
> +                }
> +              status = sig + 128; /* what sh returns for signaled processes.  */

I like the idea.
Note that setrlimit is not available on mingw or Beos, according to
gnulib's doc/posix-functions/setrlimit.texi, so you might want to test
for its existence.  Otherwise, this change would induce link failure on
those systems.

At first I was worried that this improvement would be dependent on
setrlimit success, but it appears that it cannot fail for the arguments
used here.  I wonder if it's better to assert that non-failure -- or
maybe just issue a warning, so that if it happens we'll be more likely
to get a bug report about it, rather than have users endure a subtle
difference in behavior.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.