[reSIProcate] SipStack memory leak

[Scott Godin]

...inline...

On Mon, Dec 10, 2012 at 4:23 AM, Shypytiak Taras <p-aladin at yandex.ru> wrote:

> Hi, developer's team,
> I'm using resiprocate-1.8.5 and I have observed a fiew memory leak issues:
>
> 1)  When we use SipStack::postMs. but thi leak happens only if
> applications stops nad is caused by resip/stack/TimerQueue.hxx:55.
>
> virtual ~TimerQueue()
>       {
>          while (!mTimers.empty())
>          {
>             mTimers.pop();
>          }
>       }
> Could you please implement explicit  destruction?
>

[Scott]  Not too sure what you are suggesting here.  TimeQueue is a
templatized class - we are not storing pointers in the priority_queue.
 Even the while loop isn't necessary, since the priority_queue and all it's
items should be destroyed when the mTimers member goes out of scope anyway.
 Perhaps one of the classes used in the T template parameter is not
properly cleaning up in it's destructor.  The TimerWithPayload class
appears to be a potential culprit.


> 2) Next issue is cause by resip/stack/ParserContainerBase.hxx:61(
> ParserContainerBase::clear )
>
> inline void clear() {mParsers.clear();}
> In this case freeParser is not called and we have memory leak .
> And this leak is more dangerous as ParserContainerBase::clear is called
> from  number of places(  MasterProfile::clearSupportedMethods for example ).
> Could you please implement proper ParserContainerBase::clear, through
> ParserContainerBase::pop_front for example?
>

[Scott]  Nice catch - I will fix this.  Thanks!


> Sincerely,
> Taras.
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20121211/07ea0ec5/attachment.htm>