Re: [reSIProcate] Memory leak in SipMessage.

[Dario Bozzali <Dario.Bozzali@xxxxxxxxxxx>]

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@xxxxxxxxxxxxxxx] On Behalf Of Jan Granqvist
Sent: mercoledì 4 giugno 2014 11.09
To: resiprocate-devel@xxxxxxxxxxxxxxx
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