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