From owner-freebsd-bugs@FreeBSD.ORG Fri May 7 16:39:30 2004 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D345816A4CE; Fri, 7 May 2004 16:39:30 -0700 (PDT) Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id F180243D4C; Fri, 7 May 2004 16:39:29 -0700 (PDT) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from localhost (localhost [127.0.0.1])i47NdSQC088357; Fri, 7 May 2004 23:39:29 GMT (envelope-from Tor.Egge@cvsup.no.freebsd.org) Date: Fri, 07 May 2004 23:39:27 +0000 (GMT) Message-Id: <20040507.233927.74668319.Tor.Egge@cvsup.no.freebsd.org> To: tolyar@mx.ru From: Tor Egge In-Reply-To: <200405060740.i467eJHU073117@freefall.freebsd.org> References: <200405060740.i467eJHU073117@freefall.freebsd.org> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/66242: endless loop in sh(1) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 23:39:31 -0000 > 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