Re: panic in lwpsignal

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi.
:
:I started getting this panic recently while under load.  It took me
:a couple of days to get the kernel dump because it still locks up
:while dumping.  The line number is slightly off because I inserted
:a KKASSERT() right before the if statement to validate the array index
:used in SIGISMEMBER() macro.
:
:The kernel image and the dump is available on leaf as
:~y0netan1/crash/{kern,vmcore}.26 .  The kernel is built from the source
:as of e45c80940 + some local non-kernel modifications.

    Interesting. It looks like it is trying to signal the parent
    process:

    #11 0xffffffff80293230 in exit1 (rv=<value optimized out>)
    at /usr/src/sys/kern/kern_exit.c:534
    534                     ksignal(p->p_pptr, p->p_sigparent);
    (kgdb) 

    However, p->p_pptr is ripped out from under the ksignal due to the
    child reparenting to process 1 on another cpu.  So p->p_pptr in the
    dump points to process 1, but the process passed to the ksignal is the
    'old' parent which is now gone (deadcode in structure).

    I'm guessing this is a mplock vs proc_token issue or other blocking
    issue.  Lets do this patch to start with, but it is also possible
    that we might have to hold proc_token... that the exit1() code's
    use of the mplock (mp_token now) is not sufficient.

	fetch http://apollo.backplane.com/DFlyMisc/exit01.patch

						-Matt