[Home]

Summary:ASTERISK-25269: Speex VAD: SIGSEGV when softmixing stasis-bridges
Reporter:Florian Loyau (Florian Loyau ASK)Labels:
Date Opened:2015-07-21 07:06:57Date Closed:2017-04-14 13:35:25
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Codecs/codec_speex Core/Bridging Formats/General
Versions:13.0.1 13.4.0 Frequency of
Occurrence
Constant
Related
Issues:
duplicatesASTERISK-26880 Asterisk crashes when multiple speex users join confbridge with pp_vad and dtx enabled
Environment:Debian 7/8 generic VMsAttachments:( 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/].