< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

RE: [reSIProcate] Memory leaks


If they do they must retransmit the last 18x at least every minute (this is
in RFC3261).  The default is always settable via the Profile if this is not
the case.  If you guys think I should put it back to something longer I can.

I didn't try out the timer leak fix - but it seems to make sense.

Happy Holidays All!

-----Original Message-----
From: Derek MacDonald [mailto:derek@xxxxxxxx] 
Sent: Thursday, December 23, 2004 4:28 PM
To: 'Scott Godin'; 'Dmitry Semyonov'
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Memory leaks

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.
> > > > > > _______________________________________________
> > > > > > resiprocate-devel mailing list
> > > > > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > > >
> > > > >
> > > >
> > > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > > >
> > > > >
> > > > >
> > > >
> > > ______________________________________________________________________
> > > > > Post your free ad now! http://personals.yahoo.ca
> > > > > _______________________________________________
> > > > > resiprocate-devel mailing list
> > > > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > >
> > > >
> > > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > >
> > > >
> > > >
> > >
> > > ______________________________________________________________________
> > > Post your free ad now! http://personals.yahoo.ca
> > > _______________________________________________
> > > resiprocate-devel mailing list
> > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> >
> 
> --
> ...Bye..Dmitry.
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel