[sr-dev] [dialog MI dlg_end_dlg] error when terminating a dialog in state 2 (never removed from memory)

Timo Reimann timo.reimann at 1und1.de
Fri Jul 9 16:52:43 CEST 2010


Hey Iñaki,


Iñaki Baz Castillo wrote:
> 2010/7/9 Timo Reimann <timo.reimann at 1und1.de>:
>> Hey Iñaki,
>>
>>
>> Iñaki Baz Castillo wrote:
>>> 2010/7/9 Iñaki Baz Castillo <ibc at aliax.net>:
>>>> However the current code could leak.
>>> And IMHO it leaks!. The reason is that after the CANCEL the dialog
>>> information remains as follows:
>>>
>>> dialog::  hash=3132:647756461
>>>         state:: 5
>>>         timestart:: 0
>>>         timeout:: 0
>>>         callid:: knfmgpcorrteiia at ibc-torre
>>>         from_uri:: sip:test_ibc at somedomain.org
>>>         from_tag:: vicxp
>>>         caller_contact:: sip:test_ibc at X.X.X.X
>>>         caller_cseq:: 326
>>>         caller_route_set::
>>>         caller_bind_addr:: udp:X.X.X.X:5060
>>>         to_uri:: sip:XXXXXX at somedomain.org
>>>         to_tag::
>>>         callee_contact::
>>>         callee_cseq::
>>>         callee_route_set::
>>>         callee_bind_addr::
>>>
>>> This is, there is no timestart neither timeout values, so even if the
>>> expiration time for dialgo module is set to 60 seconds, the dialog
>>> remains in memory forever!
>> I don't think that it leaks. Please have a look at the
>> get_expired_dlgs(unsigned int time) function in dlg_timer.c: The loop
>> condition to get all expired dialogs is
>>
>>  while( tl!=end && tl->timeout <= time) {
>>                    ^^^^^^^^^^^^^^^^^^^
>>    [...]
>>  }
>>
>> The unit of "time" is ticks, so the while-loop picks those dialogs for
>> cleanup whose timeout value is lower or equal the current number of
>> ticks. Certainly, this is true for a timeout of zero.
> 
> 
> Hi Timo, thanks for your response. Unfortunatelly that is not what I
> get in my tests. If now I repeat the step 5 of my first mail I sitll
> see such dialog (state 5) with timeout 0 and timestart 0, but it still
> appears when retrieving the dialog list via MI. So IMHO such
> information is obviously leaking (note that dialog module expiration
> value is 60 seconds in case).

There's a good chance you are right and I am wrong because I was arguing
on a mere theoretical basis. That is, I was being lazy and looked at
code only. :)


> Could you please perform the same experiment I've done in my first
> mail? I can reproduce it 100% of times.

Will do and report back as soon as I get to it.


Cheers,

--Timo



More information about the sr-dev mailing list