On Wed, 2009-05-20 at 09:48 +0200, Tom van der Geer wrote: > Stefan Sayer writes: > > Hello, > > > > o Peter Loeppky [05/13/09 17:21]: > >> I have a B2B application running. Every now and again, I am having an > >> issue with some threads got getting destroyed. From what I can tell, it > >> appears that it is the second legs that stays open. > > > > this happens if in your application you don't call setStopped() for > > all possible cases. > > > > Usually with b2b apps that is failed calls on the second leg. IIRC you > > need to check whether the dialog's status changes from Pending to > > Disconnected in onSipReply, or, in the caller leg, you need to call > > terminateOtherLeg(). It's not really intuitive; do you think we should > > introduce onFailedCall event handler? > > > > Stefan > Stefan, can you elaborate a bit more on this? I'm also working on a B2B > application and occasionally SEMS crashes which might be caused by too > much (or too little) session/thread cleanup. When SEMS crashes it > happens during destructing my AmB2BCallerSession derived class > (~MyCallerDialog()). It mentions: > > (8707) DEBUG: [b7257bb0] ~MyCallerDialog (MyApplication.cpp:373): > MyCallerDialog::~MyCallerDialog() > (8707) DEBUG: [b7257bb0] ~AmB2BSession (AmB2BSession.cpp:51): > relayed_req.size() = 0 > (8707) DEBUG: [b7257bb0] ~AmB2BSession (AmB2BSession.cpp:52): > recvd_req.size() = 0 > (8707) DEBUG: [b7257bb0] ~AmSipDialog (AmSipDialog.cpp:50): callid = > [email protected] > (8707) DEBUG: [b7257bb0] ~AmSipDialog (AmSipDialog.cpp:51): local_tag = > 547A01EE-4A0D5DA7000A5A3A-B7459BB0 > (8707) DEBUG: [b7257bb0] ~AmSipDialog (AmSipDialog.cpp:52): > uac_trans.size() = 1 > (8707) DEBUG: [b7257bb0] ~AmSipDialog (AmSipDialog.cpp:57): cseq = > 10; method = INVITE > (8707) DEBUG: [b7257bb0] ~AmSipDialog (AmSipDialog.cpp:60): > uas_trans.size() = 0 > *** glibc detected *** free(): invalid pointer: 0x081a5c10 *** > > or > > *** glibc detected: double free or corruption (!prev) > > Crashes are not exactly reproducible, but happen after 10 and sometimes > even 500 successful calls. Quite possibly I'm not covering all > scenario's (e.g. LEG B busy) correctly. Any hints? Thanks in advance! > Best regards, > > Tom >
I would check you code. In my installation, I am pushing a large amount of calls through the system and I don't have any crashes. Peter _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
