Date: Mon, 23 Oct 2006 11:48:34 -0400 From: John Baldwin <jhb@freebsd.org> To: David Xu <davidxu@freebsd.org> Cc: cvs-src@freebsd.org, Don Lewis <truckman@freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_exit.c Message-ID: <200610231148.35326.jhb@freebsd.org> In-Reply-To: <200610221354.57273.davidxu@freebsd.org> References: <200610220014.k9M0E5mG061752@gw.catspoiler.org> <200610221354.57273.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 22 October 2006 01:54, David Xu wrote: > 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 ? It will return to the exit1() function. :) If a process has W_EXIT set and is asleep in msleep() with PCATCH, it called msleep() from exit1() or some other number of functions in between the two. Note that this was the behavior of FreeBSD prior to the Linux threads stuff (and BSD). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610231148.35326.jhb>