Summary: | ASTERISK-27050: Crash on Transcoded Audio in PERIODIC_HOOK Function | ||||
Reporter: | Joshua Elson (joshelson) | Labels: | |||
Date Opened: | 2017-06-12 14:35:19 | Date Closed: | 2017-06-14 14:23:59 | ||
Priority: | Major | Regression? | |||
Status: | Closed/Complete | Components: | |||
Versions: | 14.5.0 | Frequency of Occurrence | |||
Related Issues: |
| ||||
Environment: | Attachments: | ( 0) coredump.txt ( 1) extensions_crash.conf ( 2) pjsip_crash.conf ( 3) verbose-output.txt | |||
Description: | This is an interesting one. Transcoding an audio file on a periodic hook will almost always cause a crash. If it does not cause a crash, it will peg a core and eventually lock up Asterisk.
Steps are as follows: The originating endpoint needs to use a higher def codec (confirmed crashing with opus,g722, and speex 16/32) The dialplan must apply a PERIODIC_HOOK to the originating channel. Playback a *.wav file on the same channel the HOOK was enabled on. (Tested this with .sln16/.gsm and things work as expected.) This usually causes a core dump of asterisk, but occasionally locks up the thread, pegging a core and making asterisk totally unresponsive. Attaching the stack trace and sample dialplan to generate the issue. | ||||
Comments: | By: Asterisk Team (asteriskteam) 2017-06-12 14:35:20.098-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: Joshua Elson (joshelson) 2017-06-12 14:36:37.658-0500 Attaching dialplan and core dump output. By: George Joseph (gjoseph) 2017-06-14 10:23:33.343-0500 I haven't been able to reproduce this even after modifying the pjsip config to force g722 on the originating channel. The only thing I don't have is your "custom/hello" file so I used the standard hello.wav. Is there something special about your hello.wav or is that just the standard one copied onto the custom directory? Also, can you do a "core set verbose 3" and make sure NOTICE is turned on before making the call and attach the output? I'd like to see the exact progress the call is making. By: Joshua Elson (joshelson) 2017-06-14 11:08:36.096-0500 Hey George. We changed this to use a standard file (vm-undelete) with the same result. Also attaching verbose logs. By: George Joseph (gjoseph) 2017-06-14 11:40:35.574-0500 Nope. Still can't reproduce. Output looks the same as mine up until the crash though. Can you move that playback to the hook in place of the wait? When 6001 answers, do a "pjsip show channelstats" and let's see exactly which codecs were negotiated on each leg. By: Joshua Elson (joshelson) 2017-06-14 11:49:23.566-0500 It actually doesn't matter what we do in the hook. We now just have it doing a verbose and returning. It still crashes when it gets to the Playback in the [p-hook-test] context. If we do the Playback on the channel before inserting the PERIODIC_HOOK it doesn't crash. Here is the channelstats output: mediang*CLI> pjsip show channelstats ...........Receive......... .........Transmit.......... BridgeId ChannelId ........ UpTime.. Codec. Count Lost Pct Jitter Count Lost Pct Jitter RTT.... =========================================================================================================== 6001-00000004 00:00:02 g722 90 0 0 0.000 86 0 0 0.003 0.000 By: George Joseph (gjoseph) 2017-06-14 14:22:53.798-0500 Finally figured it out... This was fixed last week in https://gerrit.asterisk.org/5758 I couldn't reproduce it because I was using the current 14 branch which had the fix. |