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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
