Re: [reSIProcate] TimerQueue memory leak.
Hi Taras,
It doesn't exactly just push the raw pointer onto the queue, it pushes a TimerWithPayload class onto the queue, and this class stores the raw pointer. In my commit earlier this week (with your parser leak fix) I also included a change to the BaseTimeLimitTimerQueue, TuSelectorTimerQueue and DtlsTimerQueue classes. I added destructors to call delete on the raw message pointer in these classes derived from TimerQueue - this means the messages are deleted and queue is drained by the time the TimerQueue destructor is called. This should fix the shutdown leaks you are seeing.
Scott
On Thu, Dec 20, 2012 at 6:11 AM, palladin
<p-aladin@xxxxxxxxx> wrote:
Hi developer's team,
I have written recently about memory leak in TimerQueue, and now I would like to provide use case.
If someone calls SipStack::postMS( SipStack.cxx:667 ), this causes Message::clone
SipStack::postMS(const ApplicationMessage& message, unsigned int ms,
TransactionUser* tu)
{
assert(!mShuttingDown);
/////////////////////////////////////////////
Message* toPost = message.clone();
///////////////////////////////////////////////////////////
if (tu) toPost->setTransactionUser(tu);
Lock lock(mAppTimerMutex);
mAppTimers.add(ms,toPost);
//.dcm. timer update rather than process cycle...optimize by checking if sooner
//than current timeTillNextProcess?
checkAsyncProcessHandler();
}
After that cloned toPost message is added into SipStack::mAppTimers.
toPost is a raw pointer.
TuSelectorTimerQueue::add member function just pushes raw pointer into TimerQueue::mTimers.
When we stop application TimerQueue pops it's content from mTimers in it's destructor. In case of raw pointers we get memory leak.
Sincerely,
Taras
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel