[Home]

Summary:ASTERISK-14305: [patch] Segfault after Manager Bridge
Reporter:Vincenzo Marrone (vmarrone)Labels:
Date Opened:2009-06-11 11:51:34Date Closed:2011-01-31 14:58:05.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) backtrace.txt
( 1) hangup-race-fix1.diff
( 2) hangup-race-fix4.diff
Description:I have configured the dialplan like this:

exten => _X.,1,Ringing()
exten => _X.,2,Wait(1000)
exten => _X.,3,Goto(2)
exten => _X.,4,Answer()
exten => _X.,5,Goto(2)

When a call comes in the context, by AMI, I can redirect the created channel to 4th priority for answer the call.
When I receive a Channel State UP for this channel, always by AMI, I can Originate an Async new Call and put it on the same context.
When I receive the Success Originate Response Event, finally make the Bridge for the two channels obtained.

This goes very well almost every time, and the two channels are connected between them.


If one of the channels, DURING THE EXECUTION OF THE BRIDGE, hangups, asterisk crashes.





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

Is difficult to reproduce this issue, because is very difficult hangup a channel during the little time of the execution of the bridge.

This is the log of the CLI, when all goes right:

 == Using SIP RTP CoS mark 5
   -- Executing [3287414971@voxxadefault:1] Ringing("SIP/1001-095168e8", "") in new stack
   -- Executing [3287414971@voxxadefault:2] Wait("SIP/1001-095168e8", "1000") in new stack
 == Spawn extension (voxxadefault, _X., 4) exited non-zero on 'SIP/1001-095168e8'
   -- Executing [_X.@voxxadefault:4] Answer("SIP/1001-095168e8", "") in new stack
   -- Executing [_X.@voxxadefault:5] Goto("SIP/1001-095168e8", "2") in new stack
   -- Goto (voxxadefault,_X.,2)
   -- Executing [_X.@voxxadefault:2] Wait("SIP/1001-095168e8", "1000") in new stack
 == Spawn extension (voxxadefault, _X., 13) exited non-zero on 'SIP/1001-095168e8'
   -- Executing [_X.@voxxadefault:13] PlayTones("SIP/1001-095168e8", "ring") in new stack
   -- Executing [_X.@voxxadefault:14] Goto("SIP/1001-095168e8", "2") in new stack
   -- Goto (voxxadefault,_X.,2)
   -- Executing [_X.@voxxadefault:2] Wait("SIP/1001-095168e8", "1000") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
      > Channel DAHDI/1-1 was answered.
   -- Executing [_X.@voxxadefault:2] Wait("DAHDI/1-1", "1000") in new stack
 == Spawn extension (voxxadefault, _X., 2) exited non-zero on 'Bridge/SIP/1001-095168e8<ZOMBIE>'
 == Spawn extension (voxxadefault, _X., 2) exited non-zero on 'Bridge/DAHDI/1-1<ZOMBIE>'
   -- Executing [_X.@voxxadefault:3] Goto("DAHDI/1-1", "2") in new stack
   -- Goto (voxxadefault,_X.,2)
   -- Executing [_X.@voxxadefault:2] Wait("DAHDI/1-1", "1000") in new stack
 == Spawn extension (voxxadefault, _X., 15) exited non-zero on 'DAHDI/1-1'
   -- Executing [_X.@voxxadefault:15] PlayTones("DAHDI/1-1", "busy") in new stack
   -- Executing [_X.@voxxadefault:16] Goto("DAHDI/1-1", "2") in new stack
   -- Goto (voxxadefault,_X.,2)
   -- Executing [_X.@voxxadefault:2] Wait("DAHDI/1-1", "1000") in new stack
 == Spawn extension (voxxadefault, _X., 2) exited non-zero on 'DAHDI/1-1'
   -- Hungup 'DAHDI/1-1'



Here the Log of CLI when Asterisk crashes :

 == Using SIP RTP CoS mark 5
   -- Executing [3287414971@voxxadefault:1] Ringing("SIP/1004-09d17060", "") in new stack
   -- Executing [3287414971@voxxadefault:2] Wait("SIP/1004-09d17060", "1000") in new stack
 == Spawn extension (voxxadefault, _X., 4) exited non-zero on 'SIP/1004-09d17060'
   -- Executing [_X.@voxxadefault:4] Answer("SIP/1004-09d17060", "") in new stack
   -- Executing [_X.@voxxadefault:5] Goto("SIP/1004-09d17060", "2") in new stack
   -- Goto (voxxadefault,_X.,2)
   -- Executing [_X.@voxxadefault:2] Wait("SIP/1004-09d17060", "1000") in new stack
 == Spawn extension (voxxadefault, _X., 13) exited non-zero on 'SIP/1004-09d17060'
   -- Executing [_X.@voxxadefault:13] PlayTones("SIP/1004-09d17060", "ring") in new stack
   -- Executing [_X.@voxxadefault:14] Goto("SIP/1004-09d17060", "2") in new stack
   -- Goto (voxxadefault,_X.,2)
   -- Executing [_X.@voxxadefault:2] Wait("SIP/1004-09d17060", "1000") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
      > Channel DAHDI/1-1 was answered.
   -- Executing [_X.@voxxadefault:2] Wait("DAHDI/1-1", "1000") in new stack
 == Spawn extension (voxxadefault, _X., 2) exited non-zero on 'SIP/1004-09d17060'
[Jun 11 17:24:26] WARNING[30812]: chan_sip.c:5484 sip_fixup: No SIP tech_pvt! Fixup of Bridge/SIP/1004-09d17060<ZOMBIE> failed.
[Jun 11 17:24:26] WARNING[30812]: channel.c:4246 ast_do_masquerade: Channel for type 'SIP' could not fixup channel SIP/1004-09d17060

Disconnected from Asterisk server
Executing last minute cleanups
/usr/sbin/safe_asterisk: line 138: 30734 Segmentation fault      (core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} >&/dev/${TTY} < /dev/${TTY}
Asterisk ended with exit status 139
Asterisk exited on signal 11.
Automatically restarting Asterisk.

Here the back trace of GDB:

Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  0x0051d095 in sip_indicate (ast=0x9d2ea60, condition=20, data=0x0, datalen=0)at chan_sip.c:5696
5696                    ast_rtp_new_source(p->rtp);
(gdb) bt
#0  0x0051d095 in sip_indicate (ast=0x9d2ea60, condition=20, data=0x0, datalen=0)at chan_sip.c:5696
#1  0x0808f3d3 in ast_indicate_data (chan=0x9d2ea60, _condition=20, data=0x0,datalen=0) at channel.c:3007
#2  0x08096192 in ast_channel_bridge (c0=0x9cdb318, c1=<value optimized out>,config=0x9e1b018, fo=0xb71e3318, rc=0xb71e3314) at channel.c:2951
#3  0x080b95a7 in ast_bridge_call (chan=0x9cdb318, peer=0x9d2ea60, config=0x9e1b018)at features.c:2509
#4  0x080bb65e in ast_bridge_call_thread (data=0x9e1b018) at features.c:349
ASTERISK-1  0x08142ccb in dummy_start (data=0x9df4310) at utils.c:968
ASTERISK-2  0x00b6b45b in start_thread () from /lib/libpthread.so.0
ASTERISK-3  0x00ac2e5e in clone () from /lib/libc.so.6

Comments:By: Leif Madsen (lmadsen) 2009-06-16 15:41:31

In order to move this issue forward, you will need to provide a backtrace of the issue with DONT_OPTIMIZE enabled in the "Compiler Flags" section of menuselect. After enabling, do 'make install', reproduce the issue, and then attach the backtrace as a text file to this issue. Thanks!
By: Vincenzo Marrone (vmarrone) 2009-06-18 08:54:16

Ok, thankYou! In this days i'll do this.
Sorry for the possible delay.
By: Leif Madsen (lmadsen) 2009-07-13 10:28:03

Closed due to lack of response. However, if you are able to provide the requested information, please reopen this issue and attach the requested info. Thanks!
By: Vincenzo Marrone (vmarrone) 2009-07-14 02:55:12

Sorry, I having much work... When is possible I'll post the requested information.
Thank You for all.
By: Vincenzo Marrone (vmarrone) 2009-07-22 05:20:42

Ok, finally I had some time for post the BackTrace with the DONT_OPTIMIZE enabled in the "Compiler Flags" menu of menuselect.
As a matter of fact, the log is little bit different:
Here the cli log:

      > Channel DAHDI/1-1 was answered.
   -- Executing [_X.@voxxadefault:2] Wait("DAHDI/1-1", "1000") in new stack
 == Spawn extension (voxxadefault, _X., 2) exited non-zero on 'SIP/1001-b6b02a08'
[Jul 22 12:06:06] WARNING[26244]: chan_sip.c:5484 sip_fixup: No SIP tech_pvt! Fixup of Bridge/SIP/1001-b6b02a08<ZOMBIE> failed.
[Jul 22 12:06:06] WARNING[26244]: channel.c:4246 ast_do_masquerade: Channel for type 'SIP' could not fixup channel SIP/1001-b6b02a08
 == Spawn extension (voxxadefault, _X., 2) exited non-zero on 'Bridge/DAHDI/1-1<ZOMBIE>'
[Jul 22 12:06:06] ERROR[27368]: astobj2.c:110 INTERNAL_OBJ: user_data is NULL
ERIS-1*CLI>
Disconnected from Asterisk server
Executing last minute cleanups
[root@ERIS-1 ~]# /usr/sbin/safe_asterisk: line 138: 21294 Segmentation fault      (core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} >&/dev/${TTY} < /dev/${TTY}
Asterisk ended with exit status 139
Asterisk exited on signal 11.
Automatically restarting Asterisk.


Here the backtrace of GDB:

Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  0x004cdeec in sip_indicate (ast=0x911b950, condition=20, data=0x0, datalen=0) at chan_sip.c:5696
5696                    ast_rtp_new_source(p->rtp);
(gdb) bt
#0  0x004cdeec in sip_indicate (ast=0x911b950, condition=20, data=0x0, datalen=0) at chan_sip.c:5696
#1  0x08092231 in ast_indicate_data (chan=0x911b950, _condition=20, data=0x0, datalen=0) at channel.c:3007
#2  0x08092133 in ast_indicate (chan=0x911b950, condition=20) at channel.c:2951
#3  0x08097f84 in ast_channel_bridge (c0=0x9123eb0, c1=0x911b950, config=0x91501d8, fo=0xb724726c, rc=0xb7247268) at channel.c:4745
#4  0x080bfed9 in ast_bridge_call (chan=0x9123eb0, peer=0x911b950, config=0x91501d8) at features.c:2509
ASTERISK-1  0x080b8013 in ast_bridge_call_thread (data=0x91501d8) at features.c:349
ASTERISK-2  0x08145dcd in dummy_start (data=0x9142c10) at utils.c:968
ASTERISK-3  0x00b6b45b in start_thread () from /lib/libpthread.so.0
ASTERISK-4  0x00ac2e5e in clone () from /lib/libc.so.6
By: Vincenzo Marrone (vmarrone) 2009-07-22 05:28:53

ThankYou all for interest at this issue.
By: Matthew Nicholson (mnicholson) 2009-09-15 08:26:08

Test the patch I uploaded.  This should fix your issue.
By: Matthew Nicholson (mnicholson) 2009-09-15 13:42:28

The previous patch may cause additional problems.  I have upload a new patch (hangup-race-fix4.diff) that should not cause any additional issues.
By: Vincenzo Marrone (vmarrone) 2009-09-16 06:15:33

OK, thank You very much!
How can I apply the patch? Which command?
Is right this?
# cd /path/to/asterisk/source/
#wget 'https://issues.asterisk.org/file_download.php?file_id=23817&type=bug' -O - | patch -p0
Sorry for my ignorance.
When is possible I'll repeat the test an post the results...
I hope in a success!
By: Matthew Nicholson (mnicholson) 2009-09-16 08:57:26

Yes, that command should work.  The patch is designed to work on asterisk 1.6.1.1.
By: Digium Subversion (svnbot) 2009-09-17 10:00:26

Repository: asterisk
Revision: 219136

U   branches/1.4/include/asterisk/cdr.h
U   branches/1.4/include/asterisk/channel.h
U   branches/1.4/main/channel.c

------------------------------------------------------------------------
r219136 | mnicholson | 2009-09-17 10:00:25 -0500 (Thu, 17 Sep 2009) | 10 lines

Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.

This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list.  This fix makes the channel unavabile at the time when the CDR backend is invoked.  This has been documented in include/asterisk/cdr.h.

(closes issue ASTERISK-14305)
Reported by: vmarrone
Tested by: mnicholson

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

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

http://svn.digium.com/view/asterisk?view=rev&revision=219136
By: Digium Subversion (svnbot) 2009-09-17 10:19:47

Repository: asterisk
Revision: 219139

_U  trunk/
U   trunk/include/asterisk/cdr.h
U   trunk/main/channel.c

------------------------------------------------------------------------
r219139 | mnicholson | 2009-09-17 10:19:47 -0500 (Thu, 17 Sep 2009) | 17 lines

Merged revisions 219136 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
 
 Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
 
 This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list.  This fix makes the channel unavabile at the time when the CDR backend is invoked.  This has been documented in include/asterisk/cdr.h.
 
 (closes issue ASTERISK-14305)
 Reported by: vmarrone
 Tested by: mnicholson
 
 Review: https://reviewboard.asterisk.org/r/362/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=219139
By: Digium Subversion (svnbot) 2009-09-17 10:39:58

Repository: asterisk
Revision: 219194

_U  branches/1.6.2/
U   branches/1.6.2/include/asterisk/cdr.h
U   branches/1.6.2/include/asterisk/channel.h
U   branches/1.6.2/main/channel.c

------------------------------------------------------------------------
r219194 | mnicholson | 2009-09-17 10:39:58 -0500 (Thu, 17 Sep 2009) | 24 lines

Merged revisions 219139 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r219139 | mnicholson | 2009-09-17 10:18:01 -0500 (Thu, 17 Sep 2009) | 17 lines
 
 Merged revisions 219136 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
   
   Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
   
   This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list.  This fix makes the channel unavabile at the time when the CDR backend is invoked.  This has been documented in include/asterisk/cdr.h.
   
   (closes issue ASTERISK-14305)
   Reported by: vmarrone
   Tested by: mnicholson
   
   Review: https://reviewboard.asterisk.org/r/362/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=219194
By: Digium Subversion (svnbot) 2009-09-17 10:46:00

Repository: asterisk
Revision: 219198

_U  branches/1.6.0/
U   branches/1.6.0/include/asterisk/cdr.h
U   branches/1.6.0/include/asterisk/channel.h
U   branches/1.6.0/main/channel.c

------------------------------------------------------------------------
r219198 | mnicholson | 2009-09-17 10:46:00 -0500 (Thu, 17 Sep 2009) | 24 lines

Merged revisions 219139 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r219139 | mnicholson | 2009-09-17 10:18:01 -0500 (Thu, 17 Sep 2009) | 17 lines
 
 Merged revisions 219136 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
   
   Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
   
   This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list.  This fix makes the channel unavabile at the time when the CDR backend is invoked.  This has been documented in include/asterisk/cdr.h.
   
   (closes issue ASTERISK-14305)
   Reported by: vmarrone
   Tested by: mnicholson
   
   Review: https://reviewboard.asterisk.org/r/362/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=219198
By: Digium Subversion (svnbot) 2009-09-17 10:46:05

Repository: asterisk
Revision: 219199

_U  branches/1.6.1/
U   branches/1.6.1/include/asterisk/cdr.h
U   branches/1.6.1/include/asterisk/channel.h
U   branches/1.6.1/main/channel.c

------------------------------------------------------------------------
r219199 | mnicholson | 2009-09-17 10:46:05 -0500 (Thu, 17 Sep 2009) | 24 lines

Merged revisions 219139 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r219139 | mnicholson | 2009-09-17 10:18:01 -0500 (Thu, 17 Sep 2009) | 17 lines
 
 Merged revisions 219136 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
   
   Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
   
   This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list.  This fix makes the channel unavabile at the time when the CDR backend is invoked.  This has been documented in include/asterisk/cdr.h.
   
   (closes issue ASTERISK-14305)
   Reported by: vmarrone
   Tested by: mnicholson
   
   Review: https://reviewboard.asterisk.org/r/362/
 ........
................

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

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