Summary:ASTERISK-19636: Asterisk crashes during attended transfer due to bad data pointer passed in HOLD frame from chan_iax2
Reporter:Misha Slyusarev (misha.slyusarev)Labels:
Date Opened:2012-04-04 08:36:08Date Closed:2012-05-29 10:23:09
Versions: 10.1.0 10.3.0 Frequency of
duplicatesASTERISK-17688 [patch] segfault res_musiconhold.so when called party puts call on hold
Environment:Linux host 2.6.32-220.4.1.el6.x86_64 #1 SMP Tue Jan 24 02:13:44 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux CentOS release 6.2 (Final) I've got version of Asterisk installed, but the issue reproducible on all these versions (, 10.3.0, 10.1.0).Attachments:( 0) gdb_coredump_2012_04_04_T15_25_57
( 1) gdb_coredump_bt_2012_04_04_T15_25_57
( 2) gdb_coredump_bt_full_2012_04_04_T15_25_57
Description:A call has come to the Asterisk box and got transferred to another one via IAX. On the other box the call answered and after a while the called party pressed *2 which causes an attendant call transfer. Asterisk (on the first server) got crashed and rebooted by safe_script.

In dmesg I got:
asterisk[22273]: segfault at e4002e00 ip 00007f325c163954 sp 00007f32190b1560 error 4 in res_musiconhold.so[7f325c15c000+d000]
Comments:By: Misha Slyusarev (misha.slyusarev) 2012-04-04 08:39:37.122-0500

Backtrace for the issue added

By: Misha Slyusarev (misha.slyusarev) 2012-04-04 09:17:14.609-0500

Seems the issue is relevant to ASTERISK-17688

By: Matt Jordan (mjordan) 2012-04-10 09:05:16.688-0500

First, please follow the instructions at https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace.  This guarantees that the backtrace you've uploaded contains all the information needed for developers to resolve the issue.

Second, please note the version of Asterisk that a backtrace came from.  Your issue mentions three versions of Asterisk; in tracing a backtrace we need to know what version it was generated from.  Please note that backtraces from 1.6.2 will not be useful, as that version is no longer supported for bug fixes.

By: Misha Slyusarev (misha.slyusarev) 2012-04-11 06:46:55.080-0500

I'm not quite sure about the version from which this backtraces have been received. There were a few and I took the last one, so I would say it's from 1.6.2 (I did downgrade).

Actually, it would be really hard to reproduce the issue. Since I founded out that the problem is 64-bit system I've installed the new one with 32-bit OS and switched my production on it. So the previous environment is not exists anymore.

By: Michael L. Young (elguero) 2012-05-29 10:25:50.210-0500

ASTERISK-19597 should fix this issue.