cvs commit: src/sys/kern kern_exit.c

David Xu davidxu at freebsd.org
Sun Oct 22 05:55:05 UTC 2006


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


More information about the cvs-all mailing list