[asterisk-bugs] [Asterisk 0014296]: chan_dahdi segfaulting (may be related to Bridge() application).

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14296 
====================================================================== 
Reported By:                kebl0155
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14296
Category:                   Channels/chan_dahdi
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.0.1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-01-21 08:26 CST
Last Modified:              2009-01-27 14:44 CST
====================================================================== 
Summary:                    chan_dahdi segfaulting (may be related to Bridge()
application).
Description: 
Hi,

We changed one of our apps to use the new Bridge() command today.  Since
then we've had two segfault/core dumps in chan_dahdi.

====================================================================== 

---------------------------------------------------------------------- 
 (0098896) kebl0155 (reporter) - 2009-01-27 14:44
 http://bugs.digium.com/view.php?id=14296#c98896 
---------------------------------------------------------------------- 
Hi Blitzrage,

I'm sorry the gdb output isn't as helpful as you would wish.  All the core
dumps are consistently segfaulting at the same line in chan_dahdi.c

In answer to your question, we're essentially doing a custom ACD (without
using the Queue() application).  Typically, a caller goes into a FastAGI
using the AGI() application, where they get messages and music on hold.

A Probe call is launched on behalf of the caller to find an agent, by
using the manager Originate action with a Local channel.  ${CALLERCHANNEL}
is set on this Probe call to equal the caller's original channel.

When the agent answers the call, the dialplan automatically executes the
following on the 'free' end of the local channel:

exten => _9XXX,1,Answer
exten => _9XXX,n,Bridge(${CALLERCHANNEL})
exten => _9XXX,n,Hangup

The Bridge() command will then automatically bridge the agent and the
caller.

Execution continues after the Bridge() if the caller hangs up before the
agent, so we have a Hangup statement as the next line.  Adding a one second
delay after the Bridge() command seems to have alleviated the problem, like
this:

exten => _9XXX,1,Answer
exten => _9XXX,n,Bridge(${CALLERCHANNEL})
exten => _9XXX,n,Wait(1)
exten => _9XXX,n,Hangup

We did formerly use a more complicated(!) scheme using ChannelRedirect()
and ParkedCall(), which intermittently had the same problem, so I don't
think this is specific to the Bridge() command after all - rather, this
seems to be a problem when the Hangup is executed while the channels are
still unlinking from each other at the end of the call.

Hope this helps, and best of luck! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-27 14:44 kebl0155       Note Added: 0098896                          
======================================================================