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

Re: [reSIProcate-users] memory corruption


Are you using the API's in a thread safe manner?  http://www.resiprocate.org/DUM_Threading

Scott

On Fri, Nov 11, 2011 at 10:37 AM, he yaxin <crazyplayer1983@xxxxxxxxxxxx> wrote:

Hi all,

 

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


_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/