To the best of my knowledge, this is not a known problem. What platform are you running on?
Best regards, Byron Campen Done more debugging. It looks to me that when the connection close is initiated by the peer, it is processed inside stack->process(fdset). Socket reading returns (-1), then the connection is correctly closed on this side. Then we enter the DUM process loop "while(dumUas->process())":
DialogUsageManager::process() { if (mFifo.messageAvailable()) { internalProcess(std::auto_ptr<Message>(mFifo.getNext())); } return mFifo.messageAvailable(); } When the connection is closed, there should be no more message to be processed by DUM. However, under debugger, mFifo.messageAvailable() still returns "true", and mFifo.getNext() returns _likely_ an invalid pointer to message, which leads to crash when ~auto_ptr() is called. Is this a known problem? Kind regards, Shaofeng ----- Original Message ----From: Shaofeng Li <shaofeng_li@xxxxxxxxx>To: Byron Campen <bcampen@xxxxxxxxxxxx>Cc: resiprocate-devel@xxxxxxxxxxxxxxxSent: Friday, October 26, 2007 4:27:00 PMSubject: Re: [reSIProcate] DUM process loop crashes on TCP connection close initiated by peerHi Byron, Under gdb, the segmentation fault is due to ~auto_ptr(), and that stack trace shows that the crash occurs just on the DUM process loop line "while(dumUas->process())". There is only one auto_ptr inside DialogUsageManager::process(). DialogUsageManager::process() { if (mFifo.messageAvailable()) { internalProcess(std::auto_ptr<Message>(mFifo.getNext())); } return mFifo.messageAvailable(); } My guess is that this is the auto_ptr that causes the crash when it leaves its scope and ~auto_ptr() gets called.
Kind regards, Shaofeng ----- Original Message ----From: Byron Campen <bcampen@xxxxxxxxxxxx>To: Shaofeng Li <shaofeng_li@xxxxxxxxx>Cc: resiprocate-devel@xxxxxxxxxxxxxxxSent: Friday, October 26, 2007 3:34:40 PMSubject: Re: [reSIProcate] DUM process loop crashes on TCP connection close initiated by peer You're going to have to be more specific; where is the error occurring? There are lots of places where auto_ptr is used in the code. It may be that the problem has been fixed in the latest release.Best regards,Byron Campen> Hi,>> We're running reSIProcate (rev 1.0.3) on our IPBX to connect to an > operator network for SIP trunking. The SIP trunking works fine when > the UDP transport is used. However, when we change the transport to > TCP, the SIP stack crashes on the connection close initiated by the > operator network. The test scenario is as follows:>> register to operator network using tcp transport> ... wait some time while being inactive ...> ... receive TCP [FIN, ACK] from operator network => causing DUM > process loop to crash.>> Our application and DUM/stack run in separate processes. We > basically run the typical DUM process loop as follows:>> while (!dumShutDown)> {> FdSet fdset;> stack->buildFdSet(fdset);> int err = fdset.selectMilliSeconds(stack- > >getTimeTillNextProcessMS());> assert ( err != -1 );> stack->process(fdset);> while(dumUas->process());> }>> The DUM process loop crashes (segmentation fault) on ~auto_ptr() call.>> Can anyone help?>> Is this a known problem fixed in a version later than 1.0.3?>> Kind regards,> Shaofeng>>> __________________________________________________> Do You Yahoo!?> Tired of spam? Yahoo! Mail has the best spam protection around> http://mail.yahoo.com> _______________________________________________> resiprocate-devel mailing list> resiprocate-devel@xxxxxxxxxxxxxxx> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
__________________________________________________Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
|