[reSIProcate] Memory leak in SipMessage.

Dario Bozzali Dario.Bozzali at ifmgroup.it
Wed Jun 4 09:23:28 CDT 2014


Hi all,
While executing some test using last revision we found  a leak in SipMessage, in particular in copyOutboundDecoratorsToStackCancel() and copyOutboundDecoratorsToStackFailureAck() methods.
In fact, in those methods new operator is used to create a new auto_ptr that is next used by value as argument of addOutboundDecorator() method, but pointer is never released.
I think that also in that methods we should create auto_ptr for cloned decorator as is done, for example, in DialogUsageManager::send() method.
See below the proposed change.
Thank you and kind regards,
Dario.


void
SipMessage::copyOutboundDecoratorsToStackCancel(SipMessage& cancel)
{
  std::vector<MessageDecorator*>::iterator i;
  for (i = mOutboundDecorators.begin();
       i != mOutboundDecorators.end(); i++)
  {
     if((*i)->copyToStackCancels())
     {
---        cancel.addOutboundDecorator(*(new auto_ptr<MessageDecorator>((*i)->clone())));
+++      cancel.addOutboundDecorator(std::auto_ptr<MessageDecorator>((*i)->clone()));
     }
  }
}

void
SipMessage::copyOutboundDecoratorsToStackFailureAck(SipMessage& ack)
{
  std::vector<MessageDecorator*>::iterator i;
  for (i = mOutboundDecorators.begin();
       i != mOutboundDecorators.end(); i++)
  {
     if((*i)->copyToStackFailureAcks())
     {
---        ack.addOutboundDecorator(*(new auto_ptr<MessageDecorator>((*i)->clone())));
+++     ack.addOutboundDecorator(std::auto_ptr<MessageDecorator>((*i)->clone()));
     }
  }
}


From: resiprocate-devel [mailto:resiprocate-devel-bounces at resiprocate.org] On Behalf Of Jan Granqvist
Sent: mercoledì 4 giugno 2014 11.09
To: resiprocate-devel at resiprocate.org
Subject: [reSIProcate] Memory leak in SipMessage.

Hi all,

I ran some memory leak profiling and the result showed a memory leak of 8 bytes in the SipMessage class whenever the copy constructor was called.

Looking into the constructor, method 'init' is called which in turn calls method 'clear'.
Method 'clear' executes

      // !bwc! The "invalid" 0 index.
      mHeaders.push_back(getEmptyHfvl());

But when method 'init' continues executing

   // .bwc. Clear out the pesky invalid 0 index.
   mHeaders.clear();

the memory got lost.

I assume the problem also will occur when calling the assignment operator.

Thanks
/Janne

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140604/fe14f156/attachment.htm>


More information about the resiprocate-devel mailing list