RE: RE: Re: RE: [reSIProcate] Memory leaks
Yes. I think this is a valid bug and fix. I will run some tests and if
things look good will check it in tomorrow.
Jason
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf
> Of yuhuicai
> Sent: Monday, July 26, 2004 2:42 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: 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.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>