panic: kernel diagnostic assertion "lwp_locked(l, &l->l_cpu->ci_schedstate.spc_lwplock)" failed

Hi,

I just encountered a kernel diagnostic assertion panic,
while trying
to debug a fork()/clone() problem on my -current
NetBSD/amd64 under
compat_linux.

panic: kernel diagnostic assertion "lwp_locked(l,
&l->l_cpu->ci_schedstate.spc_lwplock)"
failed: file
"/local/src/NetBSD/src/sys/kern/kern_synch.c",
line 559

I was able to reproduce it with a native application too.
Run a
process that will call fork(), stop the chils after fork
with `sysctl
-w proc.<pid>.stopfork=1', and finally attach the
stopped child with gdb.

njolylanfeust [tmp/syscall]> uname -a
NetBSD lanfeust.sis.pasteur.fr 4.99.20 NetBSD 4.99.20
(LANFEUST_DEVEL) #20: Wed May 30 18:51:24 CEST 2007 
njolylanfeust.sis.pasteur.fr:/local/src/NetBSD/obj/amd64/s
ys/arch/amd64/compile/LANFEUST_DEVEL amd64

njolylanfeust [tmp/syscall]> file fork
fork: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
for NetBSD 4.99.20, dynamically linked (uses shared libs),
not stripped
njolylanfeust [tmp/syscall]> ./fork
father pid 1722
child pid 746

njolylanfeust [tmp/syscall]> sysctl -w
proc.1722.stopfork=1
proc.1722.stopfork: 0 -> 1
njolylanfeust [tmp/syscall]> ps
 PID TTY   STAT    TIME COMMAND
 746 ttyp1 T+   0:00.00 ./fork 
1722 ttyp1 S+   0:00.00 ./fork 
njolylanfeust [tmp/syscall]> gdb ./fork 746
GNU gdb 6.5
[...]
This GDB was configured as "x86_64--netbsd"...
Attaching to program: /home/njoly/tmp/syscall/fork, process
746
[KERNEL PANIC]

panic: kernel diagnostic assertion "lwp_locked(l,
&l->l_cpu->ci_schedstate.spc_lwplock)"
failed: file
"/local/src/NetBSD/src/sys/kern/kern_synch.c",
line 559
Stopped in pid 1310.1 (gdb) at  netbsd:cpu_Debugger+0x5:    
   leave
db> mach cpu 0
using CPU 0
db> bt
cpu_Debugger() at netbsd:cpu_Debugger+0x5
panic() at netbsd:panic+0x1fc
__assert() at netbsd:__assert+0x21
setrunnable() at netbsd:setrunnable+0x2a7
proc_unstop() at netbsd:proc_unstop+0xfe
sys_ptrace() at netbsd:sys_ptrace+0xb68
syscall_plain() at netbsd:syscall_plain+0x1cf
uvm_fault(0xffff80004cab0250, 0x0, 1) -> e
kernel: page fault trap, code=0
Faulted in DDB; continuing...
db> mach cpu 1
using CPU 1
db> bt
spllower() at netbsd:spllower+0x2e
syscall_plain() at netbsd:syscall_plain+0x1c1
uvm_fault(0xffff80004cab0250, 0x0, 1) -> e
kernel: page fault trap, code=0
Faulted in DDB; continuing...

Thanks in advance,
Regards.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.

Hi Nicholas,

On Thu, May 31, 2007 at 12:31:50AM +0200, Nicolas Joly
wrote:

> I just encountered a kernel diagnostic assertion panic,
while trying
> to debug a fork()/clone() problem on my -current
NetBSD/amd64 under
> compat_linux.
> 
> panic: kernel diagnostic assertion "lwp_locked(l,
&l->l_cpu->ci_schedstate.spc_lwplock)"
failed: file
"/local/src/NetBSD/src/sys/kern/kern_synch.c",
line 559
> 
> I was able to reproduce it with a native application
too. Run a
> process that will call fork(), stop the chils after
fork with `sysctl
> -w proc.<pid>.stopfork=1', and finally attach the
stopped child with gdb.
> 
> njolylanfeust [tmp/syscall]> uname -a
> NetBSD lanfeust.sis.pasteur.fr 4.99.20 NetBSD 4.99.20
(LANFEUST_DEVEL) #20: Wed May 30 18:51:24 CEST 2007 
njolylanfeust.sis.pasteur.fr:/local/src/NetBSD/obj/amd64/s
ys/arch/amd64/compile/LANFEUST_DEVEL amd64
> 
> njolylanfeust [tmp/syscall]> file fork
> fork: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), for NetBSD 4.99.20, dynamically linked (uses shared
libs), not stripped
> njolylanfeust [tmp/syscall]> ./fork
> father pid 1722
> child pid 746
> 
> njolylanfeust [tmp/syscall]> sysctl -w
proc.1722.stopfork=1
> proc.1722.stopfork: 0 -> 1
> njolylanfeust [tmp/syscall]> ps
>  PID TTY   STAT    TIME COMMAND
>  746 ttyp1 T+   0:00.00 ./fork 
> 1722 ttyp1 S+   0:00.00 ./fork 
> njolylanfeust [tmp/syscall]> gdb ./fork 746
> GNU gdb 6.5
> [...]
> This GDB was configured as
"x86_64--netbsd"...
> Attaching to program: /home/njoly/tmp/syscall/fork,
process 746
> [KERNEL PANIC]
> 
> panic: kernel diagnostic assertion "lwp_locked(l,
&l->l_cpu->ci_schedstate.spc_lwplock)"
failed: file
"/local/src/NetBSD/src/sys/kern/kern_synch.c",
line 559
> Stopped in pid 1310.1 (gdb) at 
netbsd:cpu_Debugger+0x5:        leave
> db> mach cpu 0
> using CPU 0
> db> bt
> cpu_Debugger() at netbsd:cpu_Debugger+0x5
> panic() at netbsd:panic+0x1fc
> __assert() at netbsd:__assert+0x21
> setrunnable() at netbsd:setrunnable+0x2a7
> proc_unstop() at netbsd:proc_unstop+0xfe
> sys_ptrace() at netbsd:sys_ptrace+0xb68
> syscall_plain() at netbsd:syscall_plain+0x1cf
> uvm_fault(0xffff80004cab0250, 0x0, 1) -> e
> kernel: page fault trap, code=0
> Faulted in DDB; continuing...
> db> mach cpu 1
> using CPU 1
> db> bt
> spllower() at netbsd:spllower+0x2e
> syscall_plain() at netbsd:syscall_plain+0x1c1
> uvm_fault(0xffff80004cab0250, 0x0, 1) -> e
> kernel: page fault trap, code=0
> Faulted in DDB; continuing...

Thanks for the report & test case. This appears to be a
different
manifestation of the problem recorded in kern/36398 (kernel
diagnostic
assertion while runing a native java). I haven't yet had the
time to fix
it yet, but will be looking into it in the next couple of
days.

Andrew

On Thu, May 31, 2007 at 10:06:54AM +0100, Andrew Doran
wrote:
> 
> Thanks for the report & test case. This appears to
be a different
> manifestation of the problem recorded in kern/36398
(kernel diagnostic
> assertion while runing a native java). I haven't yet
had the time to fix
> it yet, but will be looking into it in the next couple
of days.

Yes. Bernd mailed me about it.

As ever, thanks for looking into it.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.

On Thu, May 31, 2007 at 10:06:54AM +0100, Andrew Doran
wrote:
> 
> Thanks for the report & test case. This appears to
be a different
> manifestation of the problem recorded in kern/36398
(kernel diagnostic
> assertion while runing a native java). I haven't yet
had the time to fix
> it yet, but will be looking into it in the next couple
of days.

I just tested it again, and the problem is gone with r1.189
of
sys/kern/kern_synch.c.

Thanks a lot.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.

On Fri, Jun 01, 2007 at 11:12:51PM +0200, Nicolas Joly
wrote:

> On Thu, May 31, 2007 at 10:06:54AM +0100, Andrew Doran
wrote:
> > 
> > Thanks for the report & test case. This
appears to be a different
> > manifestation of the problem recorded in
kern/36398 (kernel diagnostic
> > assertion while runing a native java). I haven't
yet had the time to fix
> > it yet, but will be looking into it in the next
couple of days.
> 
> I just tested it again, and the problem is gone with
r1.189 of
> sys/kern/kern_synch.c.

Good news, thanks.

Andrew