Hi Uwe, I see the core was not generated, so no bt :(....can you reproduce the crash? can you get a core file and a bt ?
Thanks and regards, Bogdan Uwe Kastens wrote: > Bogdan, > > Sorry for bothering again. I tried the latest trunk from svn and > opensips is dying after accessing the mysql db. > > I will attach the trace. > > BR > > Uwe > > > > Bogdan-Andrei Iancu schrieb: > >> OK - with the fix from SVN you should be able to call loose_route() as >> many times you want without any risk - just let me know if it works as >> expected. >> >> Regards, >> Bogdan >> >> Uwe Kastens wrote: >> >>> Hi Bogdan, >>> >>> Again, thanks a lot for your help. >>> >>> The loose_route() seems to cause the problem, but somehow its needed to >>> pass byes correctly to the UA. So I need to work a little on my skript. >>> >>> I will try the 1.6 ASAP and let you know the result. >>> >>> BR >>> >>> Uwe >>> >>> >>> >>> Bogdan-Andrei Iancu schrieb: >>> >>> >>>> If you could test, a fix is available on 1.6 (trunk) version - if ok, I >>>> will do the backport. >>>> >>>> Regards, >>>> Bogdan >>>> >>>> Bogdan-Andrei Iancu wrote: >>>> >>>> >>>>> Hi Uwe, >>>>> >>>>> Thanks for the traces. Looking at the opensips logs, I say you do >>>>> loose_route() twice for the ACK which looks twice for the dialog and >>>>> increase the ref twice for the dialog....this is why the ref never >>>>> gets back to 0 to allow the dialog to be destroyed.. >>>>> >>>>> Could you confirm this for me ? >>>>> >>>>> even if it's a script error , the dialog module should cope with it..I >>>>> will look for a fix. >>>>> >>>>> Thanks and regards, >>>>> Bogdan >>>>> >>>>> Bogdan-Andrei Iancu wrote: >>>>> >>>>> >>>>> >>>>>> Hi Uwe, >>>>>> >>>>>> >>>>>> Uwe Kastens wrote: >>>>>> >>>>>> >>>>>>> Hi again, >>>>>>> >>>>>>> So I think it might be a bug. One direction (UA to PSTN) works >>>>>>> everytime >>>>>>> perfectly. It doesn't matter on which side the BYE is sent. If I try >>>>>>> the >>>>>>> other direction, the dialog will not be removed. Again it won't >>>>>>> matter >>>>>>> on which side the BYE is sent - the dialog will stay active. >>>>>>> >>>>>>> >>>>>> yes, it sounds like. >>>>>> >>>>>> >>>>>>> Unfort I was not able to find out what the states and the events >>>>>>> means. >>>>>>> >>>>>>> >>>>>> You can find the meaning of each state in: modules/dialog/dlg_hash.h >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> So its not easy to debug further. >>>>>>> >>>>>>> Working direction: >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 1 to >>>>>>> state 2, due event 2 >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 2 to >>>>>>> state 3, due event 3 >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 3 to >>>>>>> state 4, due event 6 >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 4 to >>>>>>> state 4, due event 6 >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 4 to >>>>>>> state 4, due event 1 >>>>>>> >>>>>>> Not Working >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 1 to >>>>>>> state 2, due event 2 >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 2 to >>>>>>> state 2, due event 2 >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 2 to >>>>>>> state 3, due event 3 >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 3 to >>>>>>> state 5, due event 7 >>>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 5 to >>>>>>> state 5, due event 1 >>>>>>> >>>>>>> Anyone could help please? >>>>>>> >>>>>>> >>>>>> I can try : ) >>>>>> >>>>>> could you (privately if needed) please send me the the full logs for >>>>>> the entire call (debug=6) - for the non working part. >>>>>> >>>>>> Thanks and regards, >>>>>> Bogdan >>>>>> >>>>>> >>>>>>> BR >>>>>>> >>>>>>> Uwe >>>>>>> >>>>>>> >>>>>>> Uwe Kastens schrieb: >>>>>>> >>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I think the dialog is destroyed, if no reference is left. And so I >>>>>>>> asume >>>>>>>> the dialog is missing the ACK for the BYE. Or do I need to unref it >>>>>>>> manually via reply_route? I will attach the log. >>>>>>>> >>>>>>>> dialog:: hash=440:1838775488 >>>>>>>> state:: 5 >>>>>>>> user_flags:: 0 >>>>>>>> timestart:: 1246005835 >>>>>>>> timeout:: 0 >>>>>>>> callid:: [email protected] >>>>>>>> from_uri:: sip:[email protected]:5100 >>>>>>>> from_tag:: as619609ab >>>>>>>> caller_contact:: sip:[email protected]:5100 >>>>>>>> caller_cseq:: 102 >>>>>>>> caller_route_set:: >>>>>>>> caller_bind_addr:: udp:10.20.138.125:5100 >>>>>>>> to_uri:: sip:[email protected]:5100 >>>>>>>> to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl >>>>>>>> callee_contact:: sip:[email protected]:5060 >>>>>>>> callee_cseq:: 102 >>>>>>>> callee_route_set:: >>>>>>>> <sip:10.20.138.145;lr;ftag=as619609ab;did=8b1.8ddb7a7> >>>>>>>> callee_bind_addr:: udp:10.20.138.125:5100 >>>>>>>> >>>>>>>> BR >>>>>>>> >>>>>>>> Uwe >>>>>>>> >>>>>>>> Uwe Kastens schrieb: >>>>>>>> >>>>>>>> >>>>>>>>> Hello list, >>>>>>>>> >>>>>>>>> I am using DIALOG for the Concurrent calls limitation following the >>>>>>>>> tutorial. Its working pretty well - in one direction :-) >>>>>>>>> >>>>>>>>> DIALOGs from UA to PSTN are deleted after processing the BYE. In >>>>>>>>> the >>>>>>>>> other direction I see that the BYE is processed correctly, but >>>>>>>>> DIALOGs >>>>>>>>> are staying in state 5. >>>>>>>>> >>>>>>>>> Where can I find the documentation for the states? Which will >>>>>>>>> delete a >>>>>>>>> DIALOG. The BYE or the ack for the BYE? >>>>>>>>> >>>>>>>>> >>>>>>>>> BR >>>>>>>>> >>>>>>>>> Uwe >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> [email protected] >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
