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 _at__at_ -187,8 +187,6 _at__at_ 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); }Received on Thu Aug 20 2015 - 09:50:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC