Re: socket creation synchronization
Re: socket creation synchronization
- Subject: Re: socket creation synchronization
- From: Josh Graessley <email@hidden>
- Date: Mon, 5 Dec 2005 16:02:21 -0800
The assert is asserting that the mtx is not locked by the current
thread. One of two things is happening here. Either your code is
calling this from code that is already holding the lock or there is an
edge case somewhere where we take the lock but don't drop it. If you
can get the backtrace from the panic, that will help determine if
you're being called in a situation where the domain_proto_mtx lock is
already held.
-josh
On Dec 5, 2005, at 3:53 PM, Christopher Vitale wrote:
Hello,
I'm calling this:
socket_t so;
sock_socket(PF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL, NULL, NULL, &so);
This should be fine. It works almost all the time. ;-)
In my stack trace shows sock_socket calling socreate, which calls
pffindproto.
struct protosw *
pffindproto(family, protocol, type)
int family, protocol, type;
{
register struct protosw *pr;
lck_mtx_assert(domain_proto_mtx, LCK_MTX_ASSERT_NOTOWNED);
lck_mtx_lock(domain_proto_mtx);
pr = pffindproto_locked(family, protocol, type);
lck_mtx_unlock(domain_proto_mtx);
return (pr);
}
I die on the lck_mtx_assert, xnu-792.6.22/bsd/kern/uipc_domain.c:
367. I'm
still in the generic socket handling code at this point. The fact
that I'm
creating a SYSPROTO_CONTROL socket shouldn't matter. I think a
userland
socket may be holding the domain_proto_mtx lock.
A remote employee is the only one that cause the crash consistently,
I've
been relying on his panic.log. A two-machine debug remains elusive.
Thanks,
vitale
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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