I've found a bug in acquire_call() in pjsua_call.c. I found it in 1.8.5, but
1.8.10 seems to have identical code.
Examining the code, it seems that the intention is to spin for two seconds
(PJSUA_ACQUIRE_CALL_TIMEOUT) while retrying lock acquisition. However, due to
an uninitialized value of timeout.sec, I'm seeing it sleep nine times over the
course of 0-1 milliseconds (from the retry % 10 == 9 test) and then giving up
with a deadlock message.
The fix is simply to properly initialize timeout.sec to 0.
I'm also not 100% sure the sleep of retry/10 is what was intended; was this
supposed to be PJSUA_ACQUIRE_CALL_TIMEOUT/10, or something? It appears to sleep
10 times for 0 ms, then ten times for 1ms, then 2ms, and so on until 2000ms has
elapsed. That could be the desired behavior, I just wanted to mention it.
I discovered this when putting a call on hold and immediately answering another
call, with an on_stream_destroyed that took around 200ms.
Patch follows:
Index: pjsua_call.c
===================================================================
--- pjsua_call.c (revision 30221)
+++ pjsua_call.c (working copy)
@@ -1158,6 +1158,7 @@
pj_time_val time_start, timeout;
pj_gettimeofday(&time_start);
+ timeout.sec = 0 ;
timeout.msec = PJSUA_ACQUIRE_CALL_TIMEOUT;
pj_time_val_normalize(&timeout);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20110217/6a642ffe/attachment.html>
