Summary:ASTERISK-24489: Crash: Asterisk crashes when converting RTCP packet to JSON for res_hep_rtcp and report blocks are greater than 1
Reporter:Gregory Malsack (gmalsack)Labels:
Date Opened:2014-11-04 14:42:53.000-0600Date Closed:2014-11-12 18:43:05.000-0600
Status:Closed/CompleteComponents:Core/RTP Resources/res_hep_rtcp
Versions:12.4.0 13.0.0 Frequency of
is duplicated byASTERISK-24629 Asterisk crashing randomly, appears related to res_hep_rtcp
is duplicated byASTERISK-24420 segfault when Zoiper joins ConfBridge
is related toASTERISK-24498 Segmentation fault in res_hep_rtcp on attended transfer
Environment:Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-24-generic x86_64)Attachments:( 0) backtrace.txt
( 1) gdb_output.txt
( 2) gdb_output.txt
Description:Register zoiper on windows 7 professional to an endpoint configured in pjsip.conf. system runs fine, no problems. system will continue to run fine with no problems. place a call with the zoiper client. call goes through fine, and call will proceed fine all the while the opposite end is ringing. However, once the opposite end answers and the 2 channels are bridged (vitelity provider), system switches from simple_bridge tech to native_rtp, and the asterisk process ends cleanly. 4.3 seconds later, the console reconnects. No core dumps created.

problem has been reproduced reliably.

example outputs:

config files can be acquired from here:

asterisk process running as shown below:
[root@gtm-dev html]# ps -ef | grep asterisk
root      1247     1  0 Aug03 ?        00:00:00 /bin/sh /usr/sbin/safe_asterisk
root      1251  1247  0 Aug03 ?        04:38:10 /usr/sbin/asterisk -f -vvvg -c
Comments:By: Matt Jordan (mjordan) 2014-11-04 15:05:32.904-0600

Thank you for your bug report. In order to move your issue forward, we require a backtrace[1] from the core file produced after the crash. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then:

make install

After enabling, reproduce the crash, and then execute the backtrace[1] instructions. When complete, attach that file to this issue report.

[1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

By: Rusty Newton (rnewton) 2014-11-04 15:49:19.526-0600

Since you are not dumping a core, you may have to try an interactive session, like

gdb /usr/sbin/asterisk
(gdb) set args -vvvgc
(gdb) run

By: Gregory Malsack (gmalsack) 2014-11-06 10:12:27.193-0600

I'll give these items a try and let you know what the results are.


By: Gregory Malsack (gmalsack) 2014-11-06 11:35:51.516-0600

Hello Matt Jordan ~ I would have created the backtrace, and provided it. However as you can see from the original post, the core dumps are not being created when the system crashes... Thus I can not provide that information.

Rusty, I have isolated access to that server now, so I'll shutdown asterisk and run it inside of gdb like you've suggested and get back to you.


By: Gregory Malsack (gmalsack) 2014-11-06 12:08:46.998-0600

ok, ran asterisk in gdb, and was able to get the output as well as a core dump... attaching both now.


By: Gregory Malsack (gmalsack) 2014-11-06 12:09:38.175-0600

debugging output

By: Rusty Newton (rnewton) 2014-11-06 16:58:18.890-0600

[~gmalsack] the debug is a little confusing.

[~sgriepentrog] looked at the traces and it appears that you forgot to run 'bt' and 'bt full' at the point of the crash when running with gdb.

Is the other trace from a separate crash? That is you had another crash where it dumped a core?

In that case it looks like Asterisk was terminated with ^C /SIGQUIT. Did Asterisk lock up and then you had to kill it from the console? If you are getting a lock then we'll need some different debug.

Can you also run a full Asterisk 'DEBUG' log ? https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information It would be nice to have that during the crash.

By: Gregory Malsack (gmalsack) 2014-11-06 17:02:40.483-0600

ah... yea, sorry, didn't run bt while in gdb, I hit ^C to get out of gdb that's why you're seeing that... lol whoops... still a little new to gdb. I'll get you that now.

By: Gregory Malsack (gmalsack) 2014-11-06 18:55:37.089-0600

Just uploaded a new gdb_output.txt file with the bt and bt full commands run after asterisk dies.

By: Matt Jordan (mjordan) 2014-11-06 20:48:10.304-0600

This actually looks like the same crash on ASTERISK-24498.

[~gmalsack]: can you run the following in {{gdb}}:

# frame 0
# print i
# print payload->report->reception_report_count
# print payload->report->report_block[i]

By: Matt Jordan (mjordan) 2014-11-06 20:54:27.315-0600

Note: I've attached a patch to ASTERISK-24498 that I think will prevent this issue. If you could test it, that'd be appreciated.

By: Gregory Malsack (gmalsack) 2014-11-11 08:18:14.452-0600

sorry for the delay. I'll get the additional output, apply the patch, and test. If it's still a problem, I'll get the additional output again and attach.