[Home]

Summary:ASTERISK-17690: [patch] Crash while transfering a call during DTMF feature timeout.
Reporter:Irontec (irontec)Labels:
Date Opened:2011-04-13 12:03:18Date Closed:2011-05-26 08:04:21
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:1.8.3 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) backtrace
( 1) feature-end-zombie.patch
( 2) senddigit.patch
Description:When a call is being attended transfered during the time between  AST_FRAME_DTMF_BEGIN and AST_FRAME_DTMF_END, transfered channel becomes zombie (so tech data is not available), making ast_dtmf_stream segfault when tries to send the DTMF digit (at least with SIP channels).




****** ADDITIONAL INFORMATION ******

To reproduce this, set a high timeout in features.conf

featuredigittimeout = 10000     ; Max time (ms) between digits for
                               ; feature activation  (default is 500 ms)

Then do the following:
- A calls B, B answers
- A press * (or a DTFM that triggers a feature)
* AST_FRAME_DTMF_BEGIN occurs
- A sets B on Hold, calls C
- A transfer B to C
* AST_FRAME_DTMF_END occurs (Crashes while sending digit to the dropped channel)

I've attached a backtrace of the segfault, and a small patch used as workaround.

Comments:By: Gregory Hinton Nietsky (irroot) 2011-04-13 12:21:52

there is no pvt structure here this should not happen !!!
By: Irontec (irontec) 2011-04-14 03:44:51

We have found null pvt structure in other cases, for example, while hanging up zombie channel before an attended transfer. If for some reason, there's still sound in the channel (Music on hold or so), hangup process tries to release the generator (which also uses pvt structure) making asterisk crash.

Patching sip_* functions to avoid segfaults is a good practice, but it would be better to avoid full process when not required rather than just avoiding the crash.

I'm not sure about what would be the best solution. We're solving some of this segfaluts testing AST_FLAG_ZOMBIE in some processes.


By: Digium Subversion (svnbot) 2011-05-20 11:43:04

Repository: asterisk
Revision: 320057

U   branches/1.8/main/channel.c
U   branches/1.8/main/features.c

------------------------------------------------------------------------
r320057 | rmudgett | 2011-05-20 11:43:03 -0500 (Fri, 20 May 2011) | 19 lines

Crash while transferring a call during DTMF feature timeout.

When a call is being attended transferred during the time between
AST_FRAME_DTMF_BEGIN and AST_FRAME_DTMF_END, the transferred channel
becomes a zombie (so tech data is not available), making ast_dtmf_stream()
segfault when it tries to send the DTMF digit (at least with SIP
channels).

Patch based on feature-end-zombie.patch uploaded by Irontec (license 1256)

* Check for zombies when ast_channel_bridge() returns.

* Guarantee that the fo parameter value is initialized in
ast_channel_bridge() before any returns.

(closes issue ASTERISK-17690)
Reported by: Irontec
Tested by: rmudgett

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=320057
By: Digium Subversion (svnbot) 2011-05-20 11:46:03

Repository: asterisk
Revision: 320058

_U  trunk/
U   trunk/main/channel.c
U   trunk/main/features.c

------------------------------------------------------------------------
r320058 | rmudgett | 2011-05-20 11:46:03 -0500 (Fri, 20 May 2011) | 26 lines

Merged revisions 320057 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r320057 | rmudgett | 2011-05-20 11:43:02 -0500 (Fri, 20 May 2011) | 19 lines
 
 Crash while transferring a call during DTMF feature timeout.
 
 When a call is being attended transferred during the time between
 AST_FRAME_DTMF_BEGIN and AST_FRAME_DTMF_END, the transferred channel
 becomes a zombie (so tech data is not available), making ast_dtmf_stream()
 segfault when it tries to send the DTMF digit (at least with SIP
 channels).
 
 Patch based on feature-end-zombie.patch uploaded by Irontec (license 1256)
 
 * Check for zombies when ast_channel_bridge() returns.
 
 * Guarantee that the fo parameter value is initialized in
 ast_channel_bridge() before any returns.
 
 (closes issue ASTERISK-17690)
 Reported by: Irontec
 Tested by: rmudgett
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=320058
By: Digium Subversion (svnbot) 2011-05-25 11:23:13

Repository: asterisk
Revision: 320796

U   branches/1.8/include/asterisk/channel.h
U   branches/1.8/main/channel.c
U   branches/1.8/main/features.c

------------------------------------------------------------------------
r320796 | rmudgett | 2011-05-25 11:23:12 -0500 (Wed, 25 May 2011) | 17 lines

Give zombies a safe channel driver to use.

Recent crashes from zombie channels suggests that they need a safe home to
goto.  When a masquerade happens, the physical part of the zombie channel
is hungup.  The hangup normally sets the channel private pointer to NULL.
If someone then blindly does a callback to the channel driver, a crash is
likely because the private pointer is NULL.

The masquerade now sets the channel technology of zombie channels to the
kill channel driver.

Related to the following issues:
(issue ASTERISK-17690)
(issue ASTERISK-17873)

Review: https://reviewboard.asterisk.org/r/1224/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=320796
By: Digium Subversion (svnbot) 2011-05-26 08:04:21

Repository: asterisk
Revision: 320820

_U  trunk/
U   trunk/include/asterisk/channel.h
U   trunk/main/channel.c
U   trunk/main/features.c
U   trunk/main/format_cap.c

------------------------------------------------------------------------
r320820 | rmudgett | 2011-05-26 08:04:20 -0500 (Thu, 26 May 2011) | 24 lines

Merged revisions 320796 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r320796 | rmudgett | 2011-05-25 11:23:11 -0500 (Wed, 25 May 2011) | 17 lines
 
 Give zombies a safe channel driver to use.
 
 Recent crashes from zombie channels suggests that they need a safe home to
 goto.  When a masquerade happens, the physical part of the zombie channel
 is hungup.  The hangup normally sets the channel private pointer to NULL.
 If someone then blindly does a callback to the channel driver, a crash is
 likely because the private pointer is NULL.
 
 The masquerade now sets the channel technology of zombie channels to the
 kill channel driver.
 
 Related to the following issues:
 (issue ASTERISK-17690)
 (issue ASTERISK-17873)
 
 Review: https://reviewboard.asterisk.org/r/1224/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=320820