I've narrowed this down some more, and it seems that if you start an
INVITE in response to receiving a REFER, and then CANCEL the INVITE, you
get nua_i_terminated before the last nua_r_notify. I call
nua_handle_destroy in response to the nua_i_terminated, and completely
ignore the nua_r_notify. In this case, nua leaks memory.
If the last nua_r_notify comes before the nua_i_terminated (and the
resulting call to nua_handle_destroy), then no memory is leaked.
Is there something I don't understand about the usage of
nua_handle_destroy? Shouldn't I be able to destroy my handle at any time,
provided I'll never use it again?
Thanks.
--Jen
Jen Chitty
01/30/2009 03:45 PM
To: sofia-sip-devel@lists.sourceforge.net
cc:
Subject: Memory leak in 1.12.10 when cancelling an INVITE
with Replaces.
Hi,
I noticed that if I do an attended transfer (REFER with Replaces) while
the call from the transferer to the transfer destination has not been
answered yet, and the transferee then terminates the call to the
transferer with a BYE before CANCELing the INVITE with Replaces (to the
transfer destination), then a couple of weird things happen:
1. The transferee sends a duplicate NOTIFY (180 Ringing),
rather than sending a NOTIFY indicating that the INVITE w/ Replaces
has been terminated.
2. Nua leaks memory on the transferee.
But, if the transferee CANCELs the INVITE w/ Replaces to the transfer
destination before sending the BYE to the transferer, then no memory is
leaked and the final NOTIFY says "503 Service Unavailable".
After more investigation on the transferee side, it seems as though the
trigger for the memory leak and incorrect NOTIFY content is the 200 OK
from the transferer (in response to the BYE) arriving at the transferee
before the 487 Request Terminated arrives from the transfer destination.
So, even if the transferee sends the BYE to the transferer before sending
the CANCEL to the transfer destination, sometimes the 487 from the
transfer destination still arrives after the 200 from the transferer, and
the bad behaviour is still seen.
This is what I see happening if the transfer destination delays its 487
response to the CANCEL until after the transferer sends its 200 OK for the
BYE:
XFEREE XFERER XFER DEST
|------ INVITE -------->| |
|<--- 100 Trying -------| |
|<--- 180 Ringing ------| |
|<----- 200 OK ---------| |
|-------- ACK --------->| |
| |------ INVITE -------->|
| |<--- 100 Trying -------|
| |<--- 180 Ringing ------|
|<- REFER w/ Replaces --| |
|---- 202 Accepted ---->| |
|-------------------- INVITE ------------------>|
|<----------------- 100 Trying -----------------|
| |<--- 487 Req Term -----|
| |-------- ACK --------->|
|<---------------- 180 Ringing -----------------|
|-- NOTIFY (180 Ring) ->| |
|<----- 200 OK ---------| |
|-------------------- CANCEL ------------------>|
|-------- BYE --------->| |
|<------------------ 200 OK --------------------|
|<----- 200 OK ---------| |
?!->|-- NOTIFY (180 Ring) ->| |
|<- 481 Call Not Exist -| |
|<----------- 487 Request Terminated -----------|
|--------------------- ACK -------------------->|
And, nua leaks memory:
hsb_number = 1
hsb_bytes = 148
hsb_rbytes = 152
This is what I see happening if the transferer terminates its call with
the transferee by sending a BYE before the transferee terminates the call:
XFEREE XFERER XFER DEST
|------ INVITE -------->| |
|<--- 100 Trying -------| |
|<--- 180 Ringing ------| |
|<----- 200 OK ---------| |
|-------- ACK --------->| |
| |------ INVITE -------->|
| |<--- 100 Trying -------|
| |<--- 180 Ringing ------|
|<- REFER w/ Replaces --| |
|---- 202 Accepted ---->| |
|-------------------- INVITE ------------------>|
|<----------------- 100 Trying -----------------|
| |<--- 487 Req Term -----|
| |-------- ACK --------->|
|<---------------- 180 Ringing -----------------|
|-- NOTIFY (180 Ring) ->| |
|<----- 200 OK ---------| |
|<------- BYE ----------| |
|------ 200 OK -------->| |
|-------------------- CANCEL ------------------>|
|<------------------ 200 OK --------------------|
|<----------- 487 Request Terminated -----------|
|--------------------- ACK -------------------->|
|----- NOTIFY (503) --->| |
|<- 481 Call Not Exist -| |
In this sequence, the second NOTIFY is correct, but the nua still leaks
memory:
hsb_number = 1
hsb_bytes = 148
hsb_rbytes = 152
NOTE: I've also seen a segmentation violation in a call to strlen from
Sofia's thread (the thread that Sofia starts on its own, NOT the thread I
called su_root_run from). Unfortunately, (for reasons I'd rather not get
into) I can't provide you with a call stack trace. At this point, I'm
assuming that the same problem that's causing the misbehaviour described
above also caused my seg-fault, but this obviously could be an incorrect
assumption.
--Jen
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
