Re: bpfdetach blocked on lck_mtx_lock
Re: bpfdetach blocked on lck_mtx_lock
- Subject: Re: bpfdetach blocked on lck_mtx_lock
- From: Quinn <email@hidden>
- Date: Fri, 23 Feb 2007 11:55:55 +0000
At 14:36 -0800 16/2/07, Bhavesh Davda wrote:
How do I debug this?
I've no idea what causes this particular deadlock but, last I
checked, lck_mtx_lock stashes the thread of the caller in the lock.
That should help you figure out who is holding the lock you're stuck
on.
I helped a developer debug this recently, albeit in a very different
context. I've included the relevant snippet of our conversation
below. Keep in mind that this was running on Intel. I don't have
specific details handy for PowerPC, but I believe it's more-or-less
the same.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
At 16:29 -0700 3/8/06, Apple Worldwide Developer Technical Support wrote:
I took a look at the code which revealed that lck_mtx_lock stores
the current thread in the second word of the mutex to indicate that
it's locked. To confirm this, I looked at this field in the kernel
debugger over a call to socket_lock. First, I set a breakpoint on
socket_lock.
(gdb) b socket_lock
Breakpoint 1 at 0x352eb7: file
/SourceCache/xnu/xnu-792.9.72/bsd/kern/uipc_socket.c, line 2855.
I hit the breakpoint very quickly. The socket had no domain-specific locking:
(gdb) p so->so_proto->pr_lock
$2 = (int (*)()) 0
so I knew that socket_lock would use the per-domain lock
(so->so_proto->pr_domain->dom_mtx). A quick disassembly revealed
the lck_mtx_lock call within socket_lock:
(gdb) x/16i $pc
0x352eb7 <socket_lock+11>: mov 4(ëp),%esi
0x352eba <socket_lock+14>: mov 16(ëx),êx
0x352ebd <socket_lock+17>: mov 60(êx),íx
0x352ec0 <socket_lock+20>: test íx,íx
0x352ec2 <socket_lock+22>: je 0x352ed6 <socket_lock+42>
0x352ec4 <socket_lock+24>: mov %esi,8(%esp)
0x352ec8 <socket_lock+28>: mov 12(ëp),êx
0x352ecb <socket_lock+31>: mov êx,4(%esp)
0x352ecf <socket_lock+35>: mov ëx,(%esp)
0x352ed2 <socket_lock+38>: call *íx
0x352ed4 <socket_lock+40>: jmp 0x352f1a <socket_lock+110>
0x352ed6 <socket_lock+42>: mov 4(êx),êx
0x352ed9 <socket_lock+45>: mov 48(êx),êx
0x352edc <socket_lock+48>: mov êx,(%esp)
0x352edf <socket_lock+51>: call 0x194f0c <lck_mtx_lock>
0x352ee4 <socket_lock+56>: mov 12(ëp),êx
I set a breakpoint immediately before and immediately after the call:
(gdb) b *0x352edf
Breakpoint 2 at 0x352edf: file
/SourceCache/xnu/xnu-792.9.72/bsd/kern/uipc_socket.c, line 2864.
(gdb) b *0x352ee4
Breakpoint 3 at 0x352ee4: file
/SourceCache/xnu/xnu-792.9.72/bsd/kern/uipc_socket.c, line 2865.
When I hit the breakpoint before the call, the mutex was all zero:
(gdb) p *so->so_proto->pr_domain->dom_mtx
$5 = {
opaque = {0, 0, 0}
}
After the call, the second word had changed:
(gdb) p/x *so->so_proto->pr_domain->dom_mtx
$7 = {
opaque = {0x0, 0x262ad18, 0x0}
}
This word is the activation associated with the current thread. You
can print a backtrace using "showactstack":
(gdb) showactstack 0x0262ad18
activation thread pri state wait_queue wait_event
0x0262ad18 0x0262ad18 80 R
kernel_stack=0x13ef8000
stacktop=0x13efbe94
0x13efbe94 0x347490 <soo_select+48>
0x13efbeb4 0x3444da <selprocess+558>
0x13efbf74 0x3448c1 <selcontinue+25>
0x13efbf94 0x33a120 <_sleep_continue+372>
0x13efbfd4 0x197b19 <call_continuation+25>
stackbottom=0x13efbfd4
This is a match with the backtrace that you get from "bt":
(gdb) bt
#0 socket_lock (so=0x278c9e8, refcount=1) at [...]
#1 0x00347490 in soo_select (fp=0x276be10, w [...]
#2 0x003444da in selprocess (error=0, sel_pa [...]
#3 0x003448c1 in selcontinue (error=0) at /So[...]
#4 0x0033a120 in _sleep_continue (parameter=0[...]
So, if you deadlock against the socket lock, you should be able to
get the backtrace of the thread that's holding the lock from the
second word of the relevant mutex.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden