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

Fri Oct 26 12:33:10 CDT 2007

Hi Byron,

We're running on Linux 2.4, on ARM architecture (specific hardward board).

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 5:57:53 PM
Subject: Re: [reSIProcate] DUM process loop crashes on TCP connection close initiated by peer

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 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/955aef9c/attachment.htm>