Date: Fri, 07 May 2004 23:39:27 +0000 (GMT) From: Tor Egge <Tor.Egge@cvsup.no.freebsd.org> To: tolyar@mx.ru Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/66242: endless loop in sh(1) Message-ID: <20040507.233927.74668319.Tor.Egge@cvsup.no.freebsd.org> In-Reply-To: <200405060740.i467eJHU073117@freefall.freebsd.org> References: <200405060740.i467eJHU073117@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> This patch solves the problem for me:
An alternate patch is:
Index: jobs.c
===================================================================
RCS file: /home/ncvs/src/bin/sh/jobs.c,v
retrieving revision 1.67
diff -u -r1.67 jobs.c
--- jobs.c 6 Apr 2004 20:06:51 -0000 1.67
+++ jobs.c 7 May 2004 22:57:27 -0000
@@ -926,7 +926,8 @@
in_dowait--;
if (breakwaitcmd != 0) {
breakwaitcmd = 0;
- return -1;
+ if (pid <= 0)
+ return -1;
}
if (pid <= 0)
return pid;
By not returning early when breakwaitcmd is nonzero and pid is positive,
dowait() can record that the process has exited, allowing the shell to exit
normally instead of going into an infinite loop for the script provided in the
PR.
The shell can go into a similar loop if it's waiting for a child process that
another process is tracing. Your patch would cause the shell to believe the
child dead, while it's only temporarily the child of another process (the
tracer). A short sleep if errno was ECHILD would limit the resource usage.
The shell can also go into a similar loop if the child was killed by signal
127, since the shell would believe the child to have only stopped (WIFSTOPPED()
macro returns nonzero value). Disallowing signals 127 and 128 will fix that
problem.
- Tor Egge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040507.233927.74668319.Tor.Egge>