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/
