RE: Re: RE: [reSIProcate] Memory leaks
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.
> > >
> > >
> > >
> > >
> >
> >
> >
>