Summary: | ASTERISK-25269: Speex VAD: SIGSEGV when softmixing stasis-bridges | ||||
Reporter: | Florian Loyau (Florian Loyau ASK) | Labels: | |||
Date Opened: | 2015-07-21 07:06:57 | Date Closed: | 2017-04-14 13:35:25 | ||
Priority: | Major | Regression? | No | ||
Status: | Closed/Complete | Components: | Codecs/codec_speex Core/Bridging Formats/General | ||
Versions: | 13.0.1 13.4.0 | Frequency of Occurrence | Constant | ||
Related Issues: |
| ||||
Environment: | Debian 7/8 generic VMs | Attachments: | ( 0) astbt ( 1) astconsole | ||
Description: | I have a simple ARI App that (right now) adds Users to ARI Bridges for conferencing. During my testing (which might not happen often in a real case due to hold, see below), Asterisk consistently segfaults upon switching from simple_bridge to softmix (aka. as soon as it goes from passthrough to mixing, when there are more than two users).
I've tested it as consistent on 13.4.0, but have had the exact same problem previously with 13.0.1 and a different ARI Application prototype. This is likely due to softmixing as it doesn't occur in an holding bridge, and due to the user amount trigger. This sounds like a blocker to me since it prevents any use of bridges with more than two parties. However this could simply be due to my testing conditions: i simply fire a bunch of calls from the same Linphone instance for testing, meaning all but one call are on hold at any given time. I'll attempt to test this in more meaningful conditions. Asterisk Config details: - Simple SIP config with dumb friends & secret auth - Speex Codec Exclusively with most options and pp enabled (i'll test without) - Single extension setting talk detect (crashes without too) and putting the call in stasis for the application ARI Application behavior: - Upon StasisStart, setup a bunch of callbacks, and issue a join of the channel to a common mixing bridge - Upon third channel entering bridge, bridge switches to softmix and promptly crashes Issue Replication: - Configure an extension to forward to a StasisApp - Setup a StasisApp causing a channel to join a mixing bridge - Use Linphone to call three times in a row the extension Expected Result: Nothing out of the ordinary happens Actual Result: Asterisk Segfaults As you can see in backtrace, ast_format_get_name() receives a null format. This is due to fr->subclass being filled of zeroes in the above frame. I couldn't get to dig deeper as to why this happens yet... | ||||
Comments: | By: Asterisk Team (asteriskteam) 2015-07-21 07:06:58.210-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: Florian Loyau (Florian Loyau ASK) 2015-07-21 07:11:28.479-0500 GDB Backtrace By: Florian Loyau (Florian Loyau ASK) 2015-07-21 07:12:19.259-0500 Console Output. Note that the first two calls are bridged fine, then the VAD and SIP errors just before SIGSEGV when the third hits By: Florian Loyau (Florian Loyau ASK) 2015-07-21 08:04:01.956-0500 Did some more testing and it actually has nothing to do with Hold, happens even with real phones and real users However, I messed around with speex settings due to the VAD warning, and indeed pp_vad in Speex seems to be causing it. Updated the issue to include Speex as related component. By: Rusty Newton (rnewton) 2015-07-22 19:19:00.002-0500 Can you provide sample dialplan and app code that reproduces the issue just so we know exactly what calls you make? By: Florian Loyau (Florian Loyau ASK) 2015-07-23 05:25:59.797-0500 Just throwing them in a stasis-bridge in mixing mode basically I tried to reproduce with ConfBridge to no avail, so this is specifically linked to stasis-bridges somehow # git clone https://github.com/fira/AsteriskVADBug # mv /etc/asterisk /etc/asterisk.old # mv AsteriskVADBug/etc/ /etc/asterisk # asterisk -vvv -ddd -g -c # npm install ari-client # node Main.js Register in Linphone as Tester:Tester Call four time in a row the extension sigsegvme : First call goes OK Second call goes OK Third call... uh ? Fourth call doesn't go through at all, because warning: The VAD has been replaced by a hack pending a complete rewrite [1] 6540 segmentation fault (core dumped) asterisk -vvv -ddd -c -g Now disable both vad and pp_vad in codecs.conf, repeat => No segfault By: Rusty Newton (rnewton) 2015-07-28 09:40:26.499-0500 Thanks for the additional detail Florian. Can you provide a backtrace as described here: https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace Along with a debug log as described here: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Asterisk Team (asteriskteam) 2015-08-11 12:00:22.497-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 By: Sean Bright (seanbright) 2017-04-14 13:35:25.625-0500 This is fixed as of 13.15.0 with [this change|https://gerrit.asterisk.org/#/c/5262/]. |