[Home]

Summary:ASTERISK-27146: Crash during attended transfer
Reporter:Worldexe (worldexe)Labels:
Date Opened:2017-07-19 10:04:36Date Closed:2020-01-14 11:13:36.000-0600
Priority:CriticalRegression?
Status:Closed/CompleteComponents:
Versions:13.15.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I encountered a crash that occurs during attended transfer.
I checked the latest 13.x version, but I am not confident enough with Asterisk codebase to identify the potential fix; I also did not find related bugs.
I plan to upgrade to the latest 13.x version soon; hope this will fix the issue.

I am running Asterisk 13.15.0 on Ubuntu 16.04.2;
The crash occurred during attended transfer; here is what we have in logs:
{noformat}
[2017-07-19 16:53:10] WARNING[6544][C-0011e455] bridge_basic.c: Unexpected stimulus 'Transfer Target Answer' received in attended transfer state 'Blond Non-Final'
[2017-07-19 16:53:10] ERROR[6544][C-0011e455] astobj2.c: FRACK!, Failed assertion user_data is NULL (0)
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: Got 9 backtrace records
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: #0: [0x493ae4] /usr/sbin/asterisk() [0x493ae4]
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: #1: [0x4d9f2a] /usr/sbin/asterisk() [0x4d9f2a]
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: #2: [0x4d3d3d] /usr/sbin/asterisk() [0x4d3d3d]
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: #3: [0x827e70] /usr/sbin/asterisk() [0x827e70]
[2017-07-19 16:53:10] ERROR[6544][C-0011e455] astobj2.c: FRACK!, Failed assertion user_data is NULL (0)
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: Got 10 backtrace records
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: #0: [0x493f82] /usr/sbin/asterisk(__ao2_lock+0x1d2) [0x493f82]
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: #1: [0x4d9d35] /usr/sbin/asterisk() [0x4d9d35]
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: #2: [0x4d9f5c] /usr/sbin/asterisk() [0x4d9f5c]
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: #3: [0x4d3d3d] /usr/sbin/asterisk() [0x4d3d3d]
[2017-07-19 16:53:10] VERBOSE[6544][C-0011e455] logger.c: #4: [0x827e70] /usr/sbin/asterisk() [0x827e70]
{noformat}

Here is what really happened according to core dump:
{noformat}
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000005a0a27 in ast_channel_internal_bridge_channel (chan=chan@entry=0x0) at channel_internal_api.c:1454
1454            return chan->bridge_channel;
[Current thread is 1 (Thread 0x7fd0eb4ba700 (LWP 6544))]
(gdb) bt
#0  0x00000000005a0a27 in ast_channel_internal_bridge_channel (chan=chan@entry=0x0) at channel_internal_api.c:1454
#1  0x00000000005904ce in ast_channel_get_bridge_channel (chan=chan@entry=0x0) at channel.c:10629
#2  0x00000000004d9d3d in ringing (chan=0x0) at bridge_basic.c:1804
#3  blond_enter (props=props@entry=0x615000a41050) at bridge_basic.c:2315
#4  0x00000000004d9f5c in blond_nonfinal_enter (props=0x615000a41050) at bridge_basic.c:2329
#5  0x00000000004d3d3d in attended_transfer_monitor_thread (data=data@entry=0x615000a41050) at bridge_basic.c:3047
#6  0x0000000000827e70 in dummy_start (data=0x602000446f60) at utils.c:1235
#7  0x00007fd109caa6ba in start_thread (arg=0x7fd0eb4ba700) at pthread_create.c:333
#8  0x00007fd1092933dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) print chan
$1 = (const struct ast_channel *) 0x0
(gdb) frame 3
#3  blond_enter (props=props@entry=0x615000a41050) at bridge_basic.c:2315
2315            ringing(props->transfer_target);
(gdb) print props->transfer_target
$2 = (struct ast_channel *) 0x0
(gdb) print props->state
$3 = TRANSFER_BLOND_NONFINAL
{noformat}

So, {{transfer_target}} suddenly became NULL (I guess it was unref'ed by someone); those error messages in log may be related.
I can investigate other threads/info in core dump if you tell me what to search for, but I can not upload it due to privacy reasons.
Comments:By: Asterisk Team (asteriskteam) 2017-07-19 10:04:37.588-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Richard Mudgett (rmudgett) 2017-07-19 10:26:46.748-0500

FYI:  You need to enable BETTER_BACKTRACES for the inline backtraces associated with those FRACK's to be useful.
By: Rusty Newton (rnewton) 2017-07-24 13:44:05.220-0500

Regarding what Richard requested - also please attach the backtraces to the issue. If you need to you can E-mail them directly to asteriskteam@digium.com for privacy sake. However, if possible, please just sanitize and attach to the issue. It makes it very hard to track things if we have reporters sending attachments to us directly.
By: Asterisk Team (asteriskteam) 2017-08-08 12:00:02.036-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines