Re: RE: Re: RE: [reSIProcate] Memory leaks
This problem occured under the following situation:
1 The client send a NoneINVITE message to the server.
2 The Server reveived this request and response a 2xx.
3 The 2xx message is jamed by network for more than T1 microseconds, as a
result, the server will retransmit the request and set the TimerE1 to
Min(2*T1,T2).
4 The overdue 2xx received by the client that make itself enter "Completed"
state and the TimerK triggered.
5 The Server received the retransmitted request in step 3 and resend a 2xx
response.
6 The Client received the second 2xx and just ignored it because it's state is
"Completed". Later, the TimerK triggered again.
See the following code, you'll find these things happens:
else if (code >= 200)
{
// don't notify the TU of retransmissions
if (mState == Trying || mState == Proceeding)
{
sendToTU(msg); // don't delete
}
if (mIsReliable)
{
terminateClientTransaction(mId);
delete this;
}
else {
mState = Completed;
mController.mTimers.add(Timer::TimerK, mId, Timer::T4 );
}
}
> Can someone who has more intimate knowledge of TransactionState.cxx confirm
> if this proposed fix is correct? If so I can check it in.
>
> Thanks,
>
> Scott
>
> -----Original Message-----
> From: yuhuicai [mailto:yuhuicai@xxxxxxxxxxx]
> Sent: Sunday, July 11, 2004 5:57 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: Re: RE: [reSIProcate] Memory leaks
>
> I found a bug in transactionstate.cxx that may produce leak.
>
> This bug is in processClientNonInvite() method:
> else if (code >= 200)
> {
> // don't notify the TU of retransmissions
> if (mState == Trying || mState == Proceeding)
> {
> sendToTU(msg); // don't delete
> }
> if (mIsReliable)
> {
> terminateClientTransaction(mId);
> delete this;
> }
> else
> {
> mState = Completed;
> mController.mTimers.add(Timer::TimerK, mId, Timer::T4 );
>
> }
> }
> Should change to:
> else if (code >= 200)
> {
> // don't notify the TU of retransmissions
> if (mState == Trying || mState == Proceeding)
> {
> sendToTU(msg); // don't delete
> }
> else if( mState == Completed)
> {
> delete msg; //leak fixed here
> }
>
> if (mIsReliable)
> {
> terminateClientTransaction(mId);
> delete this;
> }
> else if ( mState != Completed) // prevent TimerK reproduced
> {
> mState = Completed;
> mController.mTimers.add(Timer::TimerK, mId, Timer::T4 );
>
> }
> }
>
>
>
> > Thanks, I didn't know the cvs has been migrated to svn until yesterday, so
> my version is the last version in cvs server.
> >
> > I checked out the newest version from svn this morning; however, I found
> the efficiency of my program decreased and the leak problem get worse. So I
> came back to my version and modified the transactionstate.cxx(v2681) to its
> new version(v3036), then I got the same result. I believe some new bugs have
> been
> > introduced into transactionstate.cxx since version2681.
> >
> > > Which version of resiprocate are you testing against? If you are working
> off
> > > the tarball, there are a number of known memory leaks with it. The bug
> you
> > > are talking about with MD5Stream has already been fixed in the current
> > > version of subversion. I suspect that some of the transaction related
> issues
> > > have also been fixed.
> > >
> > > Jason
> > >
> > >
> > > > -----Original Message-----
> > > > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > > > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf
> > > > Of yuhuicai
> > > > Sent: Saturday, July 10, 2004 4:00 AM
> > > > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > Subject: [reSIProcate] Memory leaks
> > > >
> > > >
> > > > I write a small test program to test the SipMessage class and
> > > > find a serious memory leak problem(VC 7.1 under win2000). The
> > > > main part of the program is:
> > > >
> > > > for(int i = 0; i < 100000; i++){
> > > > auto_ptr<SipMessage> message(Helper::makeInvite(
> > > > Sip_Target, Sip_MyContact,Sip_MyContact));
> > > > auto_ptr<SipMessage> msg200(
> > > > Helper::makeResponse(*message, 200,Sip_Target) );
> > > > }
> > > >
> > > > It just produce a INVITE message and then make a 200 response.
> > > > After those codes executed, I found about 6000K byte leaked. By
> > > > tracing the resiprocate library, finally I find the problem
> > > > located in three classes which derived from std::ostream or
> std::iostream.
> > > >
> > > > In file Md5Stream.cxx, line 49, I changed the following codes
> > > >
> > > >
> > > > MD5Stream::MD5Stream()
> > > > : std::ostream(0),
> > > > mStreambuf()
> > > > {
> > > > init(&mStreambuf);
> > > > }
> > > >
> > > > to:
> > > >
> > > > MD5Stream::MD5Stream()
> > > > : std::ostream(&mStreambuf),
> > > > mStreambuf()
> > > > {
> > > > // init(&mStreambuf);
> > > > }
> > > >
> > > > I also make the same changes to CountStream::CountStream() and
> > > > DataStream::DataStream(Data& str). Now the memory leak disappeared !
> > > > I don't know why those changes work since the
> > > > std::ostream(&mStreambuf) also calls init() in std::basic_ios
> > > > constructor, but it really eliminates the leaks.
> > > >
> > > > I still find another leak. I write two programs to test INVITE,
> > > > 200 and ACK. One program steadly send INVTE to another porgram
> > > > via lan, the second one resonse 200 to the first one. When the
> > > > sending speed is not so fast(about 10 msgs per second), no memory
> > > > leaks. While the sending speed arised to about 50 msgs per
> > > > second, memory leaked quicklly, I stop the sender program and
> > > > wait for 30 seconds or more for transactions to release; however,
> > > > many memory released but the gross memory increased.
> > > >
> > > > I think maybe the state machine for transactin has many bugs that
> > > > misbehaved when some timer overtimed(fast msg sending always make
> > > > timer overtime). I still tracing this bug but it's very hard to find.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
>
>