I have just compiled and installed a debug sipxtapi (sipxtapid.dll) on my server, and tried again. There is no change to the svn source code (rev 9768) other than the sipconnection.cpp variable initialization patch.
But I got the same problem, just after sipxtapi received a RE-INVITE... "2007-06-29T18:09:04.358000Z":1264:KERNEL:WARNING:klnta::00000000:sipXtapi:" OsMsgPool::FindFreeMsg 'MediaSignals' queue size (33) exceeds soft limit (32)\n" ... "2007-06-29T18:09:04.358000Z":1296:KERNEL:CRIT:klnta::00000000:sipXtapi:"OsM sgPool::FindFreeMsg 'MediaSignals' queue size (64) exceeds hard limit (64)\n" and my app crashed again. And I checked your other question: If I call from another phone number that works, I don't get any soft limit exceeded message. But when I call from this number, sipxtapi doesn't receive any RE-INVITE. stipus ----- Original Message ----- From: "Daniel Sigurgeirsson" <[EMAIL PROTECTED]> To: "stipus" <[EMAIL PROTECTED]>; "Alexander Chemeris" <[EMAIL PROTECTED]>; "Jhorsh Muhammed" <[EMAIL PROTECTED]> Cc: "sipxtapi-dev" <[email protected]> Sent: Friday, June 29, 2007 6:36 PM Subject: Re: [sipxtapi-dev] SipConnection.cpp: Variables initialization. Yes, I believe the bug is somewhere else. I just noticed that there was no patch for this particular bug report. Our bug is somewhere else, there must be some other variables which are being used without being initialized. Unfortunately I do not understand too well how things work inside sipxtapi, so I don't know where to look. I do know that the "MediaSignals" message pool is created in the MpMediaTask class, and it is only accessed (as far as I can see) from MpMediaTask::signalFrameStart( ). Apparently, the messages accessed from there are being sent to the mIncomingQ OsMsgQ instance (found in OsServerTask class), and the receiver of that message should probably be responsible of "freeing" the message by calling pMsg->releaseMsg(); If this is not done, then the message pool will get flooded with un-released messages which cannot be reused. Who is responsible for releasing these messages, and why it fails under certain circumstances is beyond me however. The fact that this doesn't happen all the time (only during a certain type of calls) is only to complicate matters further. Regards, Daníel _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
