[reSIProcate] DUM process loop crashes on TCP connection close initiated by peer

[Shaofeng Li]

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 at yahoo.com>
To: Byron Campen <bcampen at estacado.net>
Cc: resiprocate-devel at resiprocate.org
Sent: Friday, October 26, 2007 4:27:00 PM
Subject: Re: [reSIProcate] DUM process loop crashes on TCP connection close initiated by peer


Hi 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 at estacado.net>
To: Shaofeng Li <shaofeng_li at yahoo.com>
Cc: resiprocate-devel at resiprocate.org
Sent: Friday, October 26, 2007 3:34:40 PM
Subject: 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 at resiprocate.org
> 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20071026/10f37250/attachment.htm>