Date: Mon, 11 Sep 2006 19:47:40 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: current@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: panic: System call old.recv returning with 1 locks held Message-ID: <20060911194740.0c671c28@Magellan.Leidinger.net> In-Reply-To: <20060911100117.GA92022@garage.freebsd.pl> References: <20060910194536.1b699733@Magellan.Leidinger.net> <20060910184359.GA7152@xor.obsecurity.org> <20060910230003.28fbc780@Magellan.Leidinger.net> <20060910211556.GA9924@xor.obsecurity.org> <20060911100117.GA92022@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Pawel Jakub Dawidek <pjd@FreeBSD.org> (Mon, 11 Sep 2006 12:01:18 +0200):
> In HEAD (not sure if it was MFCed) jhb@ 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 @ 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 @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060911194740.0c671c28>