site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -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); } Thanks, _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com 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. 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. vitale smime.p7s