At 02:48 PM 6/19/2009, Joel Dodson wrote: >Hi David, > >when you say you're not in a call back function, you mean the pjsua_* >calls you are making are not done from a PJSIP callback function? Or >you mean the deadlock is not in a callback function? When I say callback I mean, on_call_state() on_incoming_call(), on_playwave_eof() those type of things. If you look at pjsua.exe you will see my model for doing most pjsip stuff. I do have some application locks. But those are much simpler than what is going on in pjsip. They are mostly for doing things like, lock a mutex, add a item to a list, unlock that same mutex. There is no concept of trylock() in my application. So far what I have seen is locking between threads with the conf mutex and the pjsua mutex. Basically if you are in conference.c get_frame and lock the conf mutex, a pjsua callback had better not come to you. For the first pjsua_ call is going to break things. But what this 70009 is I don't know. But I will look at the mutex debug listing of it next. >I'm not using PJSUA. I'm using the lower level APIs, but I ran into a >deadlock issue that would also be an issue for PJSUA. The problem was >interaction between my locking mechanism and PJSIPs. I had locks on >resources that I acquire when working on the resource. When the >resource would call some PJSIP functions, an internal lock was >acquired (one I wasn't aware of at the time). That same internal lock >is acquired in some cases before my callbacks are called. > >I had a case where one thread had my application layer resource lock >and called a PJSIP function which acquired the dialog lock. On >another thread (a PJSIP thread) the dialog lock had already been >acquired and that thread was calling one of my callbacks. My callback >was trying to acquire my application layer lock. Boom. Deadlock. > >Now I always acquire the PJSIP dialog lock before trying to acquire my >application layer resource lock. Ok...acquire the PJSIP dialog lock...my stuff is higher level than that. Which might be part of my problem. I execute pjsua_ functions but I never specifically get a pjsip lock. The pjsua_ functions do that for me. But I never found a good example of doing say audio playback or recording without using the pjsua functions. Anybody know of a good example that does that? My application is a IVR application with heavy audio playback, record, conference bridging, and get digits functionality. But if I didn't use pjsua_ functions I could break things out among multiple conference bridges which would be a good thing. Thanks, David Clark >Hope this helps. > >Joel > >On Fri, Jun 19, 2009 at 11:48 AM, David Clark<vdc1048 at tx.rr.com> wrote: > > Yea even with 1.2 I still have pjsua_call_hangup() and > pjsua_call_get_info() > > returning 70009 after like a 3 minute delay. > > I am back to a mutex debug enabled hammer test. Anybody have any ideas? > > The pjsua_call_hangup() and pjsua_call_get_info() > > are not in a callback function. The pjsua_call_get_info() is after a > > make_call and is optional. I am only doing it to get the call_id string > > the sip provider sends for tracking. Or in this case pjsip makes up. > > > > David Clark > > > > > > At 11:35 PM 6/16/2009, Nguyen Van Minh Danh wrote: > > > > Hi David > > > > Thanks for the suggestions. I was doing the playing/recording/conference > > add/remove port inside the on_call_state callback event. After some > > research, I think the issue I mentioned has got to do with this > > > > [pjsip] Infinite loop in jbuf causing deadlock, > > > http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009-March/006761.html > > > > There was a bug in jbuf.c (v1.1) which resulted in an infinite loop. The > > PJSIP release log shows that the issue has been fixed in PJSIP 1.2. So I > > upgraded to 1.2 (I was using 1.1), did not change my code at all, and the > > issue doesn't seem to appear anymore. > > > > Nevertheless, you have a valid point that a deadlock may happen > when calling > > pjsua_ calls from a PJSIP callback event. Previously I observed deadlocks > > when calling pjsua_call_makecall and pjsua_call_hangup, which could only be > > resolved by calling these APIs from a separate thread but I did not know it > > had to do with the callback event. > > > > As an experiment, I run PJSIP 1.1 with code modified to do the pjsua_ calls > > from a separate thread (and not in the PJSIP callback function) and the > > issue also does not appear again. > > > > Thanks > > _______________________________________________ > > 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 > > > > _______________________________________________ > > 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 > > > >
