[asterisk-bugs] [Asterisk 0013435]: Asterisk 1.4.21.2 crash ast_do_masquerade (segfault at 00000000000000d8 rip 0000003ad54082f9 rsp 0000000040523fb0 error)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13435 
====================================================================== 
Reported By:                geoff2010
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13435
Category:                   Core/General
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21.2 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-09-06 16:20 CDT
Last Modified:              2008-09-07 06:18 CDT
====================================================================== 
Summary:                    Asterisk 1.4.21.2 crash ast_do_masquerade (segfault
at 00000000000000d8 rip 0000003ad54082f9 rsp 0000000040523fb0 error)
Description: 
I currently have 4 asterisk systems which are all experiencing this issue. 
I was running 1.4.20.1 and have recently upgraded to the 1.4.21.2 and the
bug still exists.

I am currently using FastAGI and AMI to control the calls on our system. 
this bug seems to be caused by an AMI redirect to a new context.

I am seeing the following as the last entry in my asterisk log

[Sep  6 16:23:27] WARNING[4122] channel.c: SIP/bw-13d384c0 is already
going to masquerade as Local/OFFHOOK at acd_dial_offhook-bd26,1

What I believe leads to the crash is the following:

1 - Issue an manager originate to a Local channel into an "outdial"
context.

2 - the "outdial" context dials via SIP through our gateway provider

3 - Upon ANSWER a FastAGI script is executed which notifies a higher level
application on another server via TCP that the call was answered.  the
higher level application sends a message back to the Java server (on
another thread) which issues an AMI redirect to a new context to play "on
hold" audio to the freshly generated outbound call. 

Example:

Java Thread1 - FastAGI Script sends TCP message to server to notify of
answer

Java Thread2 - receives the TcP response from server to play a specific
"hold" audio file to the newly answered call.  This Issues an AMI redirect
to asterisk which causes the FastAGI script in Thread1 to terminate and the
call is then moved to the new "hold" context

At some point in the redirect process the system crashes with a segfault. 
This happens about every 2 hours when the system is doing a good bit of
dialing.

thanks,
Geoff
====================================================================== 

---------------------------------------------------------------------- 
 (0092156) geoff2010 (reporter) - 2008-09-07 06:18
 http://bugs.digium.com/view.php?id=13435#c92156 
---------------------------------------------------------------------- 
After looking through some application logs and analyzing the timing of
some things, i believe this is a race condition, although I am not sure
where.  Just to clarify.

1 - Originate to Local/dial at outbound
2 - [outbound] does a Dial(SIP/)
3 - [outbound] upon answer does a FastAGI()
4 - FastAGI script sends message to higher level system
5 - higher level system sends message back to Java
6 - Manager Redirect is issued to move the new SIP session away from the
first FastAGI script to another FastAGI script which will play some
specific hold music

There is < 10ms between steps 4 and 6.  When the first AGI script is
called, the channeId supplied is still the Local/ channel, so I am thinking
that the rename hasn't been completed yet.  The manager redirect is issued
on the SIP/ channel and not the Local/ channel.

It would appear that most likely the masquerade is already in progress
when i issue a redirect which appears to trigger another masquerade which
causes the crash.

I may be totally off base as I am certainly no * expert, this is just my
guess.

thanks. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-07 06:18 geoff2010      Note Added: 0092156                          
======================================================================