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