Hi all,
Following Scott’s solution, I have installed the “ServerRegistrationHandler” and set up a registration persistence manager, but the application UA was still not receiving the REGISTER message. However, after digging a bit more, I accidentally found that changing the application UA’s UDP port to 5060 did the job to at least pick up the REGISTER message to some point. I am just wondering if it is the case that a SIP registrar uses 5060 as its mandatory port number?
Although the application UA did pick up the REGISTER message, it got stuck at Ln252 in ServerRegistration.cxx:
database->lockRecord(mAor);
That’s why I said it only “pick up the REGISTER message to some point”. The following is the call stack after the code got stuck:
resip::ServerRegistration::processRegistration() at ServerRegistration.cxx:252 0x815c88d
resip::ServerRegistration::dispatch() at ServerRegistration.cxx:219 0x815c56a
resip::DialogSet::dispatch() at DialogSet.cxx:612 0x818f08a
resip::DialogUsageManager::processRequest() at DialogUsageManager.cxx:2,099 0x8117b84
resip::DialogUsageManager::incomingProcess() at DialogUsageManager.cxx:1,641 0x8114c0b
resip::DialogUsageManager::internalProcess() at DialogUsageManager.cxx:1,472 0x8113ec9
resip::DumThread::thread() at DumThread.cxx:24 0x812a4a4
threadIfThreadWrapper() at ThreadIf.cxx:51 0x8287d54
start_thread() at 0x49bd8a2e
clone() at 0x49b1e34e
The debugger did not say anything, but simply stopped at this line. My understanding is that the DUM already got the REGISTER request and it has dispatched the request up to the ServerRegistration object to “processRegistration”, according to the call stack. Something bad happens while this line “database->lockRecord(mAor)” is being executed. This is really a mysterious one. Does anybody have any clue?
Regards,
Alex
--- 11年11月24日，周四, Scott Godin <sgodin@xxxxxxxxxxxxxxx> 写道：
发件人: Scott Godin <sgodin@xxxxxxxxxxxxxxx>
主题: Re: [reSIProcate-users] memory corruption
收件人: "he yaxin" <crazyplayer1983@xxxxxxxxxxxx>
抄送: resiprocate-users@xxxxxxxxxxxxxxx
日期: 2011年11月24日,周四,下午2:27
You need to install the ServerRegistrationHandler and set a registration persistence manager:
resip::InMemoryRegistrationDatabase mRegData;
...
mDum->setServerRegistrationHandler(this);
mDum->setRegistrationPersistenceManager(&mRegData);
Scott
On Thu, Nov 24, 2011 at 9:22 AM, he yaxin <crazyplayer1983@xxxxxxxxxxxx> wrote:
|
Thanks, Scott, for being active for the reSIProcate project and providing valuable support to reSIProcate users!! I have solved that memory corruption issue and queueing the DUM commands is one of the keys to prevent the application from crashing.
I am now adding the feature of handling the REGISTER message to the application. It is expected the application can receive the REGISTER message and extract relevant information and pass it onto a non-SIP server. It is very natural to have the UA class derived from “ServerRegisterationHandler” and implement those "onXXXX" virtual functions. I gave it a go, but the application won’t be able to receive the REGISTER message and the sending SIP entity got a 408 response.
I suppose there is something more to be implemented to enable receiving a REGISTER message and I think the repro code is a good example to study. It would be greatly appreciated if anybody can get me some guidelines/hints so that I can hit the point as soon as I can. Thanks very much!
Regards,
Alex
--- 11年11月16日，周三, Scott Godin <sgodin@xxxxxxxxxxxxxxx> 写道：
日期: 2011年11月16日,周三,下午6:11
You can queue the DUM command from any thread. I don't know of any memory corruption issues with the resip code base - so you will need to use a debugger to help track down your problem. If you are using linux then there is a configure option to enable DUM thread boundary checking - that would be useful to enable to ensure you are being thread safe. It may work in windows (pre-processor define) - but I've never tried it myself.
Scott
I am now aware that I was not using the APIs in a thread safe manner, and I have modified the code to use the solution of queueing DUM commands. However, I am still getting the same memory problems. My understanding is that queueing DUM commands can be done from any thread of my own application, or am I missing something? Or how can I narrow down what is causing the memory corruption with the reSIProcate?
The stack and DUM are running in separate thread in my application and there are several other threads running in the application, too.
Cheers!
Alex
--- 11年11月15日，周二, Scott Godin <sgodin@xxxxxxxxxxxxxxx> 写道：
发件人: Scott Godin <sgodin@xxxxxxxxxxxxxxx>
主题: Re: [reSIProcate-users] memory corruption
收件人: "he yaxin" <crazyplayer1983@xxxxxxxxxxxx>
抄送: resiprocate-users@xxxxxxxxxxxxxxx
日期: 2011年11月15日,周二,下午9:27
|
I am having this memory corruption problem for a while and have not figured out what is exactly going on inside the reSIProcate.
Basically my application is about a component sitting between the SIP world and a specific non-SIP server. It is essentially a user agent which is also able to pass request up to the non-SIP server, wait for the response from the server and send back the proper response down to the SIP domain. My design is quite straightforward, which is to store a pointer to the handle( ServerRegistrationHandle, ServePagerrMessageHandle, etc.) passed in in the onXXXX method from the DUM and retrieve the handle pointer to send back the response to the SIP world after the non-SIP server gets finished with some operations.
The memory corruption problem appeared as soon as I started to test. Take the SIMPLE message traffic for example; most of the times, the first SIMPLE message gets handled successfully as expected, and the memory corruption usually happens after a second SIMPLE message is sent to the non-SIP server. (PS: the memory corruption happened even before the onMessageArrived method was called) The memory corruption error is usually either “_expression_: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)” or memory access violation with SipMessage object involved. For the “_expression_: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)” error, I was not able to see any call stack information. I was only given the option to “abort”. For the memory access violation with SipMessage object involved, the following call stack information may be helpful to diagnose the problem:
resip_sole.exe!resip::HeaderFieldValueList::~HeaderFieldValueList() Line 22 + 0x21 bytes C++
resip_sole.exe!resip::HeaderFieldValueList::`scalar deleting destructor'() + 0x16 bytes C++
resip_sole.exe!resip::SipMessage::cleanUp() Line 183 + 0x23 bytes C++
resip_sole.exe!resip::SipMessage::~SipMessage() Line 176 C++
resip_sole.exe!resip::SipMessage::`scalar deleting destructor'() + 0x16 bytes C++
resip_sole.exe!std::auto_ptr<resip::Message>::~auto_ptr<resip::Message>() Line 931 + 0x22 bytes
C++
resip_sole.exe!resip::DialogUsageManager::incomingProcess(std::auto_ptr<resip::Message> msg=auto_ptr {tu=0x0029f978 }) Line 1628 + 0x1b bytes C++
resip_sole.exe!resip::DialogUsageManager::internalProcess(std::auto_ptr<resip::Message> msg=empty) Line 1447 C++
resip_sole.exe!resip::DumThread::thread() Line 26 C++
resip_sole.exe!threadIfThreadWrapper(void * threadParm=0x0020f79c) Line 51 + 0xf bytes C++
msvcr100d.dll!_callthreadstartex() Line 314 + 0xf bytes C
msvcr100d.dll!_threadstartex(void * ptd=0x0029c6c0) Line 297 C
kernel32.dll!7747ed6c()
[Frames below may be
incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!777637f5()
ntdll.dll!777637c8()
I tried to debug the basicMessage code inside the reSIProcate when there is a SIMPLE message arriving and my understanding is that a ServerPagerMessage instance creates a 200 OK response which is a SharedPtr<SipMessage> inside the ServerPagerMessage internally and sends it out. The ServerPagerMessage instance deletes itself right after it has sent the message.
I am just wondering why this is happening. Even if I store the ServerPagerMessage handle for a few seconds, I am not disrupting anything. My best guess would be that internally stored SharedPtr<SipMessage> that somehow gets corrupted. It seems to me that there is some maintenance to be done for that SharedPtr<SipMessage>, but I still do not understand why everything is working fine in the basicMessage code.
I am working with Visual C++ 2010. Could someone shed some light on this? And what is the correct way to handle the SipMessage object and SharedPtr<SipMessage> in reSIProcate? Thanks very much!
Regards,
Alex
|