[Home]

Summary:ASTERISK-21297: Segmentation fault on hangup in in ast_bridged_channel
Reporter:German Becker (gbecker)Labels:
Date Opened:2013-03-18 10:00:04Date Closed:2017-12-19 09:47:39.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General Core/Bridging
Versions:11.0.1 Frequency of
Occurrence		Occasional
Related
Issues:
Environment:Ubuntu 10.04.2 Kernel 2.6.38Attachments:( 0) backtrace.txt
( 1) full-recortado.txt
Description:Function ast_bridged_channel in main/channel.c generates segmentation fault. It happens seldom, I couldn't reproduce, but I think it happens when releasing call at both channels at the same time, timing issue.

Here is the function:

{code}
struct ast_channel *ast_bridged_channel(struct ast_channel *chan)
{
       struct ast_channel *bridged;
       bridged = ast_channel_internal_bridged_channel(chan);
       if (bridged && ast_channel_tech(bridged)->bridged_channel)
               bridged = ast_channel_tech(bridged)->bridged_channel(chan, bridged);
       return bridged;
}
{code}

The segfault rises because bridged is not NULL, but ast_channel_tech(bridged) is NULL so the dereference produces a segfault. I'm not sure why it is null, but I think it is related to timing as said before.
A possible fix would be to check that ast_channel_tech(bridged) is not null.
i.e:

{code}
struct ast_channel *ast_bridged_channel(struct ast_channel *chan)
{
       struct ast_channel *bridged;
       bridged = ast_channel_internal_bridged_channel(chan);
       if (bridged && ast_channel_tech(bridged) &&
          ast_channel_tech(bridged)->bridged_channel)
               bridged = ast_channel_tech(bridged)->bridged_channel(chan, bridged);
       return bridged;
}
{code}
Comments:By: German Becker (gbecker) 2013-03-18 10:01:58.392-0500

Here is a backtrace showing the segfault:

Program terminated with signal 11, Segmentation fault.
#0  0x0000000000474356 in ast_bridged_channel (chan=0x7fa22401cdb8) at channel.c:7360
7360 if (bridged && ast_channel_tech(bridged)->bridged_channel)
(gdb) bt
#0  0x0000000000474356 in ast_bridged_channel (chan=0x7fa22401cdb8) at channel.c:7360
#1  0x00007fa237787598 in sip_hangup (ast=0x7fa22401cdb8) at chan_sip.c:6827
#2  0x000000000048824c in ast_hangup (chan=0x7fa22401cdb8) at channel.c:2832
#3  0x00000000005330a2 in __ast_pbx_run (c=0x7fa22401cdb8, args=<value optimized out>) at pbx.c:6268
#4  0x00000000005344bb in pbx_thread (data=0x188f7e8) at pbx.c:6360
#5  0x0000000000574e8b in dummy_start (data=<value optimized out>) at utils.c:1030
#6  0x00007fa24f8039ca in start_thread (arg=<value optimized out>) at pthread_create.c:300
#7  0x00007fa2508c370d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#8  0x0000000000000000 in ?? ()
By: Rusty Newton (rnewton) 2013-03-21 15:58:13.095-0500

Can you follow the steps under https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationAfterACrash for your core dump and attach the two resulting backtraces as separate files. Please use "More Actions > Attach Files" and do not attach the output inline.  Hit "Send Back" when you are done. Thanks!


By: German Becker (gbecker) 2013-03-21 16:30:56.259-0500

The backtraces
By: German Becker (gbecker) 2013-03-21 16:32:15.808-0500

full log, filtered by the call id that caused the segmentation fault
By: German Becker (gbecker) 2013-03-21 16:34:48.139-0500

Attached the backtrace. I have also attaced the log filtered by the call that caused the crash, in case it might help. I see there might be a trancoding issue (sangoma transcoding) but that should not make the bridging make a segmentation fault..
By: German Becker (gbecker) 2013-03-21 16:35:40.930-0500

(see last comment)
By: Matt Jordan (mjordan) 2013-03-29 09:42:05.727-0500

It's probably good to note that this occurred when two SIP channels couldn't be made compatible:

{noformat}
[Mar 16 19:47:54] WARNING[13963][C-00000857] channel.c: Unable to set write format on channel SIP/in.voipi.com.ar-000010af to alaw
[Mar 16 19:47:54] WARNING[13963][C-00000857] channel.c: Can't make SIP/asteriskld2-000010ae and SIP/in.voipi.com.ar-000010af compatible
[Mar 16 19:47:54] WARNING[13963][C-00000857] features.c: Bridge failed on channels SIP/asteriskld2-000010ae and SIP/in.voipi.com.ar-000010af
{noformat}

By: Joshua C. Colp (jcolp) 2017-12-19 04:52:37.521-0600

Have you experienced this under Asterisk 13? Bridging was completely rewritten and changed, so it may not occur.
By: German Becker (gbecker) 2017-12-19 09:42:08.355-0600

No I didn't. I'm not actively using Asterisk now. I guess if no one has reported the issue this can be closed.
By: Joshua C. Colp (jcolp) 2017-12-19 09:47:39.764-0600

Closing per reporter.