RE: [reSIProcate] Memory leaks

[Dmitry Semyonov <dsemyonov@xxxxxxx>]

Hi,

With Kaiduan's fix the leak has gone away.

Thanks and Merry Christmas to everybody!


On Thu, 23 Dec 2004, Derek MacDonald wrote:

> The stale call timeout was long for a reason; IVR systems can keep you in
> the early media state for an arbitrary amount of time.  Was this leak still
> present w/ the TimerQueue destructor change Kaiduan suggested?
> 
> --Derek
> 
> 
> 
> > -----Original Message-----
> > From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> > Sent: Thursday, December 23, 2004 10:06 AM
> > To: 'Dmitry Semyonov'; Derek MacDonald
> > Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [reSIProcate] Memory leaks
> > 
> > I just changed the default StaleCallTime to 3 minutes.  Note:
> > StaleCallTime
> > is the amount of allowable time between the last received 1xx response and
> > the final 2xx response before the dialog is terminated
> > 
> > -----Original Message-----
> > From: Dmitry Semyonov [mailto:dsemyonov@xxxxxxx]
> > Sent: Thursday, December 23, 2004 12:38 PM
> > To: Derek MacDonald
> > Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [reSIProcate] Memory leaks
> > 
> > Derek, Kaiduan,
> > 
> > I do not use forced shutdown.
> > I'll try to describe simple case.
> > 
> > Make a call, then drop it (via ClientInviteSession::end()) in
> > Ringing state. Then there are two cases:
> > a) Shutdown DUM gracefully;
> > b) Wait > 5 min, then shutdown DUM gracefully.
> > 
> > In the case (a) I see two 28 bytes leaks.
> > In the case (b) I see one 28 byte leak.
> > 
> > The leaks come from the same operator new, and were described in
> > previous messages.
> > 
> > BTW, I've just noticed that default value for StaleCallTimer is 3600
> > seconds (1 hour) rather than 3 minutes. Isn't that too big?
> > 
> > On Tue, 21 Dec 2004, Derek MacDonald wrote:
> > 
> > > Okay, that sounds good; the initial description implied that all timers
> > were
> > > leaking, but I completely believe in a shutdown memory leak.
> > >
> > > > -----Original Message-----
> > > > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:resiprocate-
> > > > devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of kaiduan xie
> > > > Sent: Tuesday, December 21, 2004 4:13 PM
> > > > To: Derek@xxxxxxxx; 'Dmitry Semyonov'; resiprocate-
> > > > devel@xxxxxxxxxxxxxxxxxxx
> > > > Subject: RE: [reSIProcate] Memory leaks
> > > >
> > > > Derek,
> > > >
> > > > Please consider the following case:
> > > >
> > > > 1) User sign on
> > > > 2) make a call to another user,
> > > > 3) the call just lasts 1 minutes, and hangups the call
> > > > 4) sign off
> > > > 5) shutdown DUM using
> > > > DialogUsageManagement::forceshutdown()
> > > > The call stale timer is 3 minutes.
> > > >
> > > > The memory leak comes out.
> > > >
> > > > The reason of the memory leak is that when the call
> > > > finishes, DUM donot cancel the CallStale timer, and
> > > > donot release the associated memory, and DUM is
> > > > shutdown and has no chance to process the DUM time
> > > > out. So, the memory leaks.
> > > >
> > > > kaiduan
> > > >
> > > >  --- Derek MacDonald <derek@xxxxxxxx> wrote:
> > > > > Hi Guys,
> > > > >
> > > > > Be very careful; are you certain that the message
> > > > > isn't being deleted by the
> > > > > application? For example, DUM puts deletes all
> > > > > message that it gets from the
> > > > > SipStack, so the memory associated with the
> > > > > timer(the message passed in to
> > > > > postMS) will be deleted.  I doubt that this is
> > > > > really a memory leak.
> > > > >
> > > > > I added a virtual destructor to ExternalDns, so
> > > > > ares_destroy should be
> > > > > called now.
> > > > >
> > > > > --Derek
> > > > >
> > > > > > -----Original Message-----
> > > > > > From:
> > > > > resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > > > > [mailto:resiprocate-
> > > > > > devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > > > > kaiduan xie
> > > > > > Sent: Tuesday, December 21, 2004 11:57 AM
> > > > > > To: Dmitry Semyonov;
> > > > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > > > Subject: Re: [reSIProcate] Memory leaks
> > > > > >
> > > > > > Dimitry,
> > > > > >
> > > > > > You may try to add the following destructor in
> > > > > > TimerQueue.cxx:
> > > > > >
> > > > > > //xkd-2004-11-4
> > > > > > TimeLimitTimerQueue::~TimeLimitTimerQueue()
> > > > > > {
> > > > > >    // delete the message associated with the timer
> > > > > >    for (std::multiset<Timer>::iterator i =
> > > > > > mTimers.begin(); i != mTimers.end(); ++i)
> > > > > >   {
> > > > > >     if (i->getMessage())
> > > > > >              delete i->getMessage();
> > > > > >   }
> > > > > > }
> > > > > >
> > > > > > kaiduan
> > > > > >
> > > > > >  --- Dmitry Semyonov <dsemyonov@xxxxxxx> wrote:
> > > > > > > Hello!
> > > > > > >
> > > > > > > I see several memory leaks with the r3746
> > > > > version of
> > > > > > > reSIProcate
> > > > > > > on Windows platform:
> > > > > > >
> > > > > > > 1. It seems ares_destroy() is never called,
> > > > > although
> > > > > > > it has to be,
> > > > > > > according to the code. Probably, this is due to
> > > > > > > misconfiguration of my
> > > > > > > project settings... Does anybody else see this
> > > > > leak?
> > > > > > >
> > > > > > > 2. A message created inside the following
> > > > > function
> > > > > > > is never deleted.
> > > > > > >
> > > > > > > Message*
> > > > > > > DumTimeout::clone() const
> > > > > > > {
> > > > > > >    return new DumTimeout(*this);
> > > > > > > }
> > > > > > >
> > > > > > > The function is called from within
> > > > > > >
> > > > > > > void
> > > > > > > SipStack::postMS(const ApplicationMessage&
> > > > > message,
> > > > > > > unsigned int ms)
> > > > > > > {
> > > > > > >    assert(!mShuttingDown);
> > > > > > >    Message* toPost = message.clone();
> > > > > > >    Lock lock(mAppTimerMutex);
> > > > > > >    mAppTimers.add(Timer(ms, toPost));
> > > > > > > }
> > > > > > >
> > > > > > > and the message is added then to some kind of
> > > > > > > TimerQueue.
> > > > > > >
> > > > > > > Can someone familiar with the above code look
> > > > > into
> > > > > > > this problem?
> > > > > > > TIA

-- 
...Bye..Dmitry.