cvs commit: src/sys/kern kern_exit.c

[mjacob at freebsd.org]

Are these changes why 9 out of ten reboots for me go into panic with:

panic: signal pending

?

On Sun, 22 Oct 2006, 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 ?
>
> David Xu
>