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).
Could you please perform the same experiment I've done in my first mail? I can reproduce it 100% of times.
Nevertheless, I think the current dialog module should be hotfixed such that dlg_end_dlg doesn't end dialogs in the "early" state simply because it's not capable of doing so. The upcoming, refurbished dialog module should do better though.
Great :)