Re: panic: System call old.recv returning with 1 locks held

From: Alexander Leidinger <Alexander_at_Leidinger.net>
Date: Sun, 10 Sep 2006 23:00:03 +0200
Quoting Kris Kennaway <kris_at_obsecurity.org> (Sun, 10 Sep 2006 14:43:59 -0400):

> Enable DEBUG_LOCKS and DEBUG_VFS_LOCKS then run 'show lockedvnods'
> from DDB to find out where the lockmgr lock was acquired.

I've enabled them (and WITNESS, INVARIANTS and DIAGNOSTICS) and rebuild
the kernel. Not much files where rebuild.

show lockedvnods did not show any locks. Other show XXX commands did
show nothing too. show lockchain showed a process. It's send01 (a LTP
testcase). The ddb bt command showed not much more. I got "syscall
-90" (dup2?) and the registers eip=0x28120706, esp=0xbfbfe9fc and
ebp=0xbfbfea28.

While rebooting I got another panic:
---snip---
<118> log ICMP redirect=YES
<118>.
<118>Mounting NFS file systems:


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x7572747b
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc04e3035
stack pointer           = 0x28:0xd494988c
frame pointer           = 0x28:0xd4949898
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 427 (mount_nfs)
trap number             = 12
panic: page fault
Uptime: 47s
Physical memory: 503 MB

(kgdb) bt
#0  doadump () at pcpu.h:166
During symbol reading, Incomplete CFI data; unspecified registers at
0xc049569e.#1  0xc0495dc1 in boot (howto=0x104)
at ../../../kern/kern_shutdown.c:409 #2  0xc04958bd in panic
(fmt=0xc05a5d32 "%s") at ../../../kern/kern_shutdown.c:565 #3
0xc058db72 in trap_fatal (frame=0xd494984c, eva=0x7572747b)
at ../../../i386/i386/trap.c:867 #4  0xc058dcdd in trap_pfault
(frame=0xd494984c, usermode=0x0, eva=0x7572747b)
at ../../../i386/i386/trap.c:776 #5  0xc058e04f in trap (frame= {tf_fs
= 0x8, tf_es = 0x28, tf_ds = 0x28, tf_edi = 0x75727473, tf_esi =
0xc27fa5a8, tf_ebp = 0xd4949898, tf_isp = 0xd4949878, tf_ebx =
0xc05ef780, tf_edx = 0x10000000, tf_ecx = 0x4, tf_eax = 0xc05b95d6,
tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc04e3035, tf_cs = 0x20,
tf_eflags = 0x10202, tf_esp = 0xc05ef780, tf_ss = 0xc27fa5a8})
at ../../../i386/i386/trap.c:461 #6  0xc057fefa in calltrap ()
at ../../../i386/i386/exception.s:138 #7  0xc04e3035 in vfs_filteropt
(opts=0xc05b95d6, legal=0xc2960ae4) at ../../../kern/vfs_mount.c:1648
#8  0xc2949dd9 in ?? () #9  0xc05b95d6 in ?? () #10 0xc2960ae4 in ?? ()
#11 0x000003a1 in ?? () #12 0x00000008 in ?? () #13 0xc0607758 in
w_lock_list_free () #14 0xc05b46a4 in ?? () #15 0xc05aff94 in ?? () #16
0xc2460010 in ?? () #17 0xd49498d8 in ?? () #18 0xc04ba3fb in
fixup_filename (file=0xc05ef780 " �^�")
at ../../../kern/subr_witness.c:764 #19 0xc04e2244 in vfs_donmount
(td=0xc26c66c0, fsflags=0xc292d000, fsoptions=0xd4949bb4)
at ../../../kern/vfs_mount.c:947 #20 0xc04e3962 in kernel_mount
(ma=0xc26c3610, flags=0x10000000) at pcpu.h:163 #21 0xc2949671 in ?? ()
#22 0xc26c3610 in ?? () #23 0x10000000 in ?? ()
#24 0xc26c3610 in ?? ()
#25 0xc295dd48 in ?? ()
#26 0xd4949bfc in ?? ()
#27 0x00000058 in ?? ()
#28 0x00000003 in ?? ()
#29 0x082081b0 in ?? ()
#30 0x00000010 in ?? ()
#31 0x00000002 in ?? ()
#32 0x00000000 in ?? ()
#33 0x082d0120 in ?? ()
#34 0x0000001c in ?? ()
#35 0x00008240 in ?? ()
#36 0x00002000 in ?? ()
#37 0x00002000 in ?? ()
#38 0x00002000 in ?? ()
#39 0x0000000a in ?? ()
#40 0x0000000a in ?? ()
#41 0x00000010 in ?? ()
#42 0x00000001 in ?? ()
#43 0x00000000 in ?? ()
#44 0x00000009 in ?? ()
#45 0x0804c8a0 in ?? ()
#46 0x00000003 in ?? ()
#47 0x0000003c in ?? ()
#48 0x0000001e in ?? ()
#49 0x0000003c in ?? ()
#50 0xc04e37cb in mount (td=0xc26c3610, uap=0xd4949bfc)
at ../../../kern/vfs_mount.c:767 #51 0xc04e37e0 in mount
(td=0xc26c66c0, uap=0xc26c38a0) at ../../../kern/vfs_mount.c:769 #52
0xc058e520 in syscall (frame= {tf_fs = 0x3b, tf_es = 0x3b, tf_ds =
0x3b, tf_edi = 0xbfbfef77, tf_esi = 0xbfbfedec, tf_ebp = 0xbfbfee58,
tf_isp = 0xd4949d64, tf_ebx = 0xbfbfe9ec, tf_edx = 0xbfbfe9ec, tf_ecx =
0xbfbfe96c, tf_eax = 0x15, tf_trapno = 0xc, tf_err = 0x2, tf_eip =
0x280c37a7, tf_cs = 0x33, tf_eflags = 0x246, tf_esp = 0xbfbfe9c4, tf_ss
= 0x3b}) at ../../../i386/i386/trap.c:1006 #53 0xc057ff4f in
Xint0x80_syscall () at ../../../i386/i386/exception.s:191 #54
0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?)
---snip---

Does not look very promising to me...

And while I'm at it: "WITNESS: spin lock pps not in order list"

Tomorrow I will comment out the send01 test and try again if it still
panics. If it doesn't we can at least have a look what send01 does.

Bye,
Alexander.

-- 
   25: Multithreaded
          Wir mußten ein Flußdiagramm malen, um es zu debuggen. (Kristian
          Köhntopp)
http://www.Leidinger.net  Alexander _at_ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild _at_ FreeBSD.org  : PGP ID = 72077137
Received on Sun Sep 10 2006 - 18:59:49 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:00 UTC