[OpenSIPS-Users] 1.6 and mysql => crash Re: DIALOG not deletedon BYE

brett at nemeroff.com brett at nemeroff.com
Wed Jul 1 17:40:27 CEST 2009


Wouldbthis error manifest without the registrar module?

I saw dialog counts incorrect on a stateful loadbalancer I built and was hoping this had something to do with it.

-Brett
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Bogdan-Andrei Iancu <bogdan at voice-system.ro>

Date: Wed, 01 Jul 2009 18:38:34 
To: <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] 1.6 and mysql => crash Re: DIALOG not deleted
 on BYE


Just to keep the list informed - the error had nothing to do with mysql, 
was because of the latest changes on the REGISTRAR module - the bug was 
found and fixed on SVN.

Regards,
Bogdan

Bogdan-Andrei Iancu wrote:
> 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:: 240f6fed145ac8251915f50d3d54be78 at 10.20.138.105
>>>>>>>>>     from_uri:: sip:9904090 at 10.20.138.105:5100
>>>>>>>>>     from_tag:: as619609ab
>>>>>>>>>     caller_contact:: sip:9904090 at 10.20.138.105:5100
>>>>>>>>>     caller_cseq:: 102
>>>>>>>>>     caller_route_set::
>>>>>>>>>     caller_bind_addr:: udp:10.20.138.125:5100
>>>>>>>>>     to_uri:: sip:4315302290 at asn2.domain.de:5100
>>>>>>>>>     to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl
>>>>>>>>>     callee_contact:: sip:4315302290 at 10.20.139.62: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
>>>>>>>>> Users at lists.opensips.org
>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>                               
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>>                       
>>>>>>>>               
>>>>>>>>                 


_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


More information about the Users mailing list