Hey Iñaki,
Iñaki Baz Castillo wrote:
2010/7/9 Timo Reimann timo.reimann@1und1.de:
Hey Iñaki,
Iñaki Baz Castillo wrote:
2010/7/9 Iñaki Baz Castillo ibc@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@ibc-torre from_uri:: sip:test_ibc@somedomain.org from_tag:: vicxp caller_contact:: sip:test_ibc@X.X.X.X caller_cseq:: 326 caller_route_set:: caller_bind_addr:: udp:X.X.X.X:5060 to_uri:: sip:XXXXXX@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