Re: Re: RE: [reSIProcate] Memory leaks

["yuhuicai" <yuhuicai@xxxxxxxxxxx>]

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.
> > >
> > >
> > >
> > >
> > 
> > 
> > 
>