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

Quoting Pawel Jakub Dawidek <pjd_at_FreeBSD.org> (Mon, 11 Sep 2006 12:01:18 +0200):

> In HEAD (not sure if it was MFCed) jhb_at_ added code to track number of
> mutexes/sx-locks acquired/released. So bascially this panic can happen
> when you leak a lock of any kind.
> 
> 'show alllocks' has to show them when the kernel (and modules) is
> compiled with WITNESS.

exclusive sleep mutex so_snd r=0 (0xc2b204c4) locked _at_ kern/uipc_socket.c:984

---snip---
(kgdb) bt
#0  doadump () at pcpu.h:166
During symbol reading, Incomplete CFI data; unspecified registers at
0xc049569e.#1  0xc043c4a5 in db_fncall (dummy1=0xc04b058b, dummy2=0x0,
dummy3=0xffffffff, dummy4=0xd5f34a7c "")
at ../../../ddb/db_command.c:481 #2  0xc043c77c in db_command_loop ()
at ../../../ddb/db_command.c:396 #3  0xc043dfce in db_trap (type=0x3,
code=0x0) at ../../../ddb/db_main.c:221 #4  0xc04b08d7 in kdb_trap
(type=0x3, code=0x0, tf=0x0) at ../../../kern/subr_kdb.c:502 #5
0xc058e1a4 in trap (frame= {tf_fs = 0x8, tf_es = 0x28, tf_ds = 0x28,
tf_edi = 0x100, tf_esi = 0xc05b4a30, tf_ebp = 0xd5f34c3c, tf_isp =
0xd5f34c28, tf_ebx = 0xd5f34c64, tf_edx = 0xc05b03be, tf_ecx =
0xc05b2a79, tf_eax = 0xc05b2a69, tf_trapno = 0x3, tf_err = 0x0, tf_eip
= 0xc04b058b, tf_cs = 0x20, tf_eflags = 0x282, tf_esp = 0xd5f34c58,
tf_ss = 0xc0495870}) at ../../../i386/i386/trap.c:620 #6  0xc057fefa in
calltrap () at ../../../i386/i386/exception.s:138 #7  0xc04b058b in
kdb_enter (msg=0xc05b2a69 "KDB: enter: %s\n") at cpufunc.h:60 #8
0xc0495870 in panic (fmt=0xc05b4a30 "witness_warn")
at ../../../kern/kern_shutdown.c:549 #9  0xc04bac2e in witness_warn
(flags=0x1, lock=0x0, fmt=0xc05cc56b "System call %s returning")
at ../../../kern/subr_witness.c:1358 #10 0xc058e61f in syscall (frame=
{tf_fs = 0x3b, tf_es = 0x3b, tf_ds = 0x3b, tf_edi = 0x28060ca0, tf_esi
= 0x0, tf_ebp = 0xbfbfea28, tf_isp = 0xd5f34d64, tf_ebx = 0x9, tf_edx =
0x2817bff4, tf_ecx = 0xbfbfea00, tf_eax = 0xffffffa6, tf_trapno = 0xc,
tf_err = 0x2, tf_eip = 0x28120706, tf_cs = 0x33, tf_eflags = 0x247,
tf_esp = 0xbfbfe9fc, tf_ss = 0x3b}) at ../../../i386/i386/trap.c:1055
#11 0xc057ff4f in Xint0x80_syscall ()
at ../../../i386/i386/exception.s:191 #12 0x00000033 in ?? () Previous
frame inner to this frame (corrupt stack?)
---snip---

How to track this down?

The LTP test which causes this is send01 ("Verify that send() returns
the proper errno for various failure cases") executed as a linux
program:
http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/kernel/syscalls/send/send01.c?revision=1.6&view=markup

Bye,
Alexander.

-- 
Love sometimes expresses itself in sacrifice.
		-- Kirk, "Metamorphosis", stardate 3220.3
http://www.Leidinger.net  Alexander _at_ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild _at_ FreeBSD.org  : PGP ID = 72077137