RE: [reSIProcate] Bug in TransactionState::processClientInvite
I removed the extra delete and committed the fix. Thanks for pointing this
out.
Scott
-----Original Message-----
From: Ulrich Findeisen [mailto:Ulrich.Findeisen@xxxxxxx]
Sent: Friday, March 11, 2005 10:22 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Bug in TransactionState::processClientInvite
Hi,
I run into an access violation while testing with a SIP phone using TCP. I
found the reason for the access violation in method
TransactionState::processClientInvite (TransactionState.cxx, revision 3831,
line 605):
else if (code >= 300)
{
// When in either the "Calling" or "Proceeding" states, reception of a
// response with status code from 300-699 MUST cause the client
// transaction to transition to "Completed".
if (mIsReliable)
{
// Stack MUST pass the received response up to the TU, and the client
// transaction MUST generate an ACK request, even if the transport is
// reliable
SipMessage* invite = mMsgToRetransmit;
-> delete mMsgToRetransmit;
mMsgToRetransmit = Helper::makeFailureAck(*invite, *sip);
delete invite;
// want to use the same transport as was selected for Invite
assert(mTarget.getType() != UNKNOWN_TRANSPORT);
sendToWire(mMsgToRetransmit);
sendToTU(msg); // don't delete msg
terminateClientTransaction(mId);
delete this;
}
Accessing *invite used in Helper::makeFailureAck is not valid because
"delete mMsgToRetransmit;" was called before. Therefore, the additional
"delete mMsgToRetransmit;" (added in revision 3795 to fix memory leaks) is
redundant because "delete invite;" is called directly after
Helper::makeFailureAck.
Regards,
Ulrich
--
SMS bei wichtigen e-mails und Ihre Gedanken sind frei ...
Alle Infos zur SMS-Benachrichtigung: http://www.gmx.net/de/go/sms
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel