pjsip version 1.1 gotcha #2 with work around.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



i think you have great skills to debug  deadlock situations in pjsip.
can you give me a  good advice  to debug pjsip/pjsua mutex stuff (log-level, debug outputs etc.)

i have a situation that pjsip got 100% processor use. i think i have a deadlock.

  regards
    mark




________________________________
Von: David Clark <vdc1048 at tx.rr.com>
An: pjsip list <pjsip at lists.pjsip.org>; pjsip list <pjsip at lists.pjsip.org>
Gesendet: Donnerstag, den 14. Mai 2009, 22:22:56 Uhr
Betreff: [pjsip] pjsip version 1.1 gotcha #2 with work around.

This is similar to gotcha #1.  So
I will go into less detail.  If the on_call_state() handler which
gets hangup 
notifications calls pjsua_recorder_destroy().  The box can stop
communicating after that for the following reason.
1) pjsua_recorder_destroy() locks pjsua mutex.
2) pjsua_recorder_destroy() locals conf mutex indirectly by calling
pjsua_conf_remove_port().  

But if conf mutex is locked in port audio clock thread get_frame() at the
point of the call.  

You will block waiting for conf mutex and other threads will never get
pjsua mutex.

Work around: don't call pjsua_recorder_destroy() in on_call_state()
signal the application thread to wait up and do it
in the application thread. 

David Clark



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090515/e7e2fd6a/attachment.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux