Re: [reSIProcate-users] memory corruption

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

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

On Wed, Nov 16, 2011 at 12:27 PM, he yaxin <crazyplayer1983@xxxxxxxxxxxx> wrote:

Thanks, 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

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/