On Wed, Aug 19, 2015 at 04:52:56PM -0500, Mark Felder wrote:
> panic: children list
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe01228ea840
> vpanic() at vpanic+0x189/frame 0xfffffe01228ea8c0
> kassert_panic() at kassert_panic+0x132/frame 0xfffffe01228ea930
> kern_procctl_single() at kern_procctl_single+0x81c/frame
> 0xfffffe01228eaa00
> kern_procctl() at kern_procctl+0x223/frame 0xfffffe01228eaa50
> sys_procctl() at sys_procctl+0xa5/frame 0xfffffe01228eaae0
> amd64_syscall() at amd64_syscall+0x282/frame 0xfffffe01228eabf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe01228eabf0

The fired assert means that there was a reaper process with some children
but without descendands to be reaped.  Hm, I can imagine this situation
to happen if e.g. some not-reaper forks and then acquires reaper status.
The patch below removes too aggressive asserts.

Still, it would be interesting to look into the process table.  Please
repeat the procedure to panic, then in ddb do 'ps'.  After that do
'dump' and please keep kernel.debug and vmcore around.  First I want to look
at the ps output.

diff --git a/sys/kern/kern_procctl.c b/sys/kern/kern_procctl.c
index d65ba5a..8ef72901 100644
--- a/sys/kern/kern_procctl.c
+++ b/sys/kern/kern_procctl.c
@@ -187,8 +187,6 @@ reap_status(struct thread *td, struct proc *p,
        } else {
                rs->rs_pid = -1;
-               KASSERT(LIST_EMPTY(&reap->p_reaplist), ("reap children list"));
-               KASSERT(LIST_EMPTY(&reap->p_children), ("children list"));
        return (0);
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to