OK, I think I tracked this one down. on_call_state has the PJ lock. I use a lock on my structure that manages what call slots are active and related information. Sometimes, I need to count the active calls. To do this, I lock my lock then call pjsua_call_get_conf_port (which locks the PJ lock) to make sure it has a valid port. No port, no active call (i..e. could be just recently terminated or on hold.) Another routine locks my lock, then calls any PJ function (locking the PJ lock.) Thus we get deadlock. Does PJ really need to maintain the lock while calling my on_call_setup? -Norman On Dec 20, 2007, at 2:49 PM, Norman Franke wrote: > Any idea what can cause this? It dies in pjsip_inv_answer called by > pjsua_call_answer while sending a code 180. > > 14:09:35.234 pjsua_call.c Timed-out trying to acquire PJSUA mutex > (possibly system has deadlocked) in pjsua_call_get_conf_port() > ../src/pjsip-ua/sip_inv.c:1666: failed assertion `inv->invite_tsx' > Program received signal: "SIGABRT". > > Norman Franke > ASD, Inc. > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
