[EMAIL PROTECTED] wrote:
> I have a problem with unitializing sipxtapi that occurs maybe 5% of the 
> time. It crashes in OsTimerTask.
>
> When we call destroyTimerTask in sipxtapi uninitialize, a message is 
> sent to timertask to shut it down. Before it is fully shut down, in 
> handlemessage we empty the timer queue, so the timers arent fired in the 
> OsTimerTask::run just before we exit the loop.
> This would work if at the time of sending shutdown message we were 
> blocked in receiveMessage in OsTimerTask.
>
> But it can occur, that due to processing of previous message we are just 
> about to fire timers. There shouldn't be any timers left at the time we 
> call destroyTimerTask, but unfortunately there is one left - the one(or 
> even more) created in SipRefreshMgr::rescheduleRequest which isn't 
> deleted at all and is in timer queue in OsTimerTask during call of 
> destroyTimerTask. Of course the message queue of these timers is invalid 
> and when we try to send a message to it, it crashes.
>
> I used __FUNCTION__ macro as OsTimer constructor parameter (and remember 
> the value inside timer) to track down these unruly timers.
>
> This bug is very bad, because it not only causes a crash, but also a 
> memory leak in SipXTackLib. In SipRefreshMgr::rescheduleRequest we 
> create new timer on the line
>
> // Make a copy for the timer
> SipMessage* timerRegisterMessage = new SipMessage(*request);
>
> OsTimer* timer = new OsTimer(&mIncomingQ, (int)timerRegisterMessage
> mpTimer = timer;
>
> but then we assign it to mpTimer which is a class member variable, thus 
> we lose pointer to old OsTimer if we use 2 or more lines. Since we have 
> no pointer to it we can't delete it, but we don't even delete the one 
> mpTimer we have in destructor.
>
> So this leaks not only 1 OsTimer instance per line, but also the 
> associated SipMessage copy. I was wondering where the leaked SipMessages 
> come from that show up at shutdown of my program, I thought they were 
> from singletons or something but it seems this is the reason, as I do 
> sipxreinitialize if I want to switch sip profile to register with 
> another provider.
>
>
> Jaroslav Libak
>
> _______________________________________________
> sipxtapi-dev mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
>
>   
To be more precise, the timer and message aren't deleted if the timer is 
never fired due to shutdown or sipxtapi reinitialization.
If timer fires and is received by handlemessage in SipRefreshMgr then it 
and the message are deleted.

I think it would be sufficient to store all the timers somewhere (minus 
those that got deleted in handlemessage) and delete them in destructor. 
What do you think?

I noticed there is also SipRefreshManager class that should replace this 
old buggy manager. When is that about to happen?
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

Reply via email to