Re: [reSIProcate] SipStack memory leak
Changes for these leaks have been committed to SVN main line. Thanks for reporting them.
Scott
On Tue, Dec 11, 2012 at 3:54 PM, Scott Godin
<sgodin@xxxxxxxxxxxxxxx> wrote:
...inline...
On Mon, Dec 10, 2012 at 4:23 AM, Shypytiak Taras
<p-aladin@xxxxxxxxx> 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!