From owner-cvs-all@FreeBSD.ORG Sun Oct 22 05:55:05 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C753616A40F; Sun, 22 Oct 2006 05:55:04 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: Don Lewis Date: Sun, 22 Oct 2006 13:54:57 +0800 User-Agent: KMail/1.8.2 References: <200610220014.k9M0E5mG061752@gw.catspoiler.org> In-Reply-To: <200610220014.k9M0E5mG061752@gw.catspoiler.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200610221354.57273.davidxu@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_exit.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 05:55:05 -0000 On Sunday 22 October 2006 08:14, Don Lewis wrote: > On 21 Oct, David Xu wrote: > > davidxu 2006-10-21 23:59:15 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern kern_exit.c > > Log: > > Since revision 1.333 of kern_sig.c no longer uses P_WEXIT, the change > > opened a race window which can cause memory leak in signal queue. > > Here we free memory for signal queue when process state is set to > > PRS_ZOMBIE. > > > > Revision Changes Path > > 1.291 +8 -2 src/sys/kern/kern_exit.c > > I wonder if the earlier change is what broke portupgrade after I > upgraded from an August 31st version of current to yesterday's version. > The symptoms were random processes dying from SIGHUP. It was easy to > reproduce by just going to a port directory and running > script foo make clean > a few times. I'd randomly see make complain about a non-zero exit > status from uname or some other sub-process. I tracked the problem back > to the SIGHUP bit being set in td2's sigqueue in fork1(). As a > workaround, I added a call to sigqueue_init() where td2 gets bzero'ed. > > Disappearing back into the void ... But I am still worrried by these signal changes, if an exiting process can be sent a signal, and msleep will interrupted in cleanup code, where the code will return to ? in normal case, code will return to userland, and signal will be removed and delivered, but if a thread is in exit1(), where the code can be returned to ? if a cleanup procedure is interrupted, isn't there is any resource leak or dead-loop if it is retried because signal is never removed ? David Xu