Project

General

Profile

Bug #1996

Updated by y0n3t4n1 3 months 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.

Back