Bug #1996
Updated by y0n3t4n1 over 2 years ago
Hi. Apparently a few hours of pbulk test can trigger this panic (this is on x86_64 and the kernel is built from source as of 5347900e6). As opposed to what KKASSERT claims, p->p_lock doesn't hold the non-zero value in the frame 5: #4 0xffffffff802ad259 in panic (fmt=0xffffffff804f212a "assertion: %s in %s") at /usr/src/sys/kern/kern_shutdown.c:799 #5 0xffffffff802989a1 in kern_wait (pid=<value optimized out>, status=0xffffffe05e997a74, options=1528637672, rusage=0x0, res=0xffffffe05e997b58) at /usr/src/sys/kern/kern_exit.c:901 #6 0xffffffff80298c4e in sys_wait4 (uap=0xffffffe05e997b58) at /usr/src/sys/kern/kern_exit.c:754 #7 0xffffffff804b580c in syscall2 (frame=0xffffffe05e997c08) at /usr/src/sys/platform/pc64/x86_64/trap.c:1182 #8 0xffffffff804ae53f in Xfast_syscall () at /usr/src/sys/platform/pc64/x86_64/exception.S:318 #9 0x000000000000002b in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (kgdb) fr 5 #5 0xffffffff802989a1 in kern_wait (pid=<value optimized out>, status=0xffffffe05e997a74, options=1528637672, rusage=0x0, res=0xffffffe05e997b58) at /usr/src/sys/kern/kern_exit.c:901 901 KKASSERT(p->p_lock == 0); (kgdb) p p->p_lock $1 = 0 I'm not sure if this is a problem in kgdb or a result of optimization, or it's an MP race.