[Home]

Summary:ASTERISK-28800: core: SIGSEGV on DTMF when some modules not loaded
Reporter:Adrien Martin (AdrienMartin)Labels:patch
Date Opened:2020-04-02 08:30:52Date Closed:
Priority:MajorRegression?Yes
Status:Open/NewComponents:Channels/General
Versions:16.7.0 16.8.0 16.9.0 Frequency of
Occurrence		Constant
Related
Issues:
is duplicated byASTERISK-28911 Segmentation Fault on Voicemail Menu
is duplicated byASTERISK-29002 asterisk 17.x crash
is duplicated byASTERISK-29068 Crashes due to "channel.c: Resolve issue with receiving SIP INFO packets for DTMF"
Environment:Attachments:( 0) core.tar.gz
( 1) core-brief.txt
( 2) core-full.txt
( 3) core-locks.txt
( 4) core-thread1.txt
( 5) extensions.conf
( 6) inbound.conf
( 7) modules.conf
( 8) peers.conf
( 9) rtp.conf
(10) sip.conf
(11) tag-16.14.1-no-timer.patch
Description:During a call when the caller send a DTMF (using the method negotiated in SDP and configured for the peer) asterisk ends with SIGSEGV.

The versions I tested (using chan_sip) were :
* 16.2.1 with debian patches (which we are using at the moment), no crash,
* 16.6.0 with debian patches, no crash,
* 16.7.0/16.8.0/16.9.0 with debian patches, segfault,
* 16.9.0 built from upstream archive without packaging nor patches, segfault.

The crash happens while playing a .wav or in a call or with Answer+Echo.
It happens either before the call is answered or after.
It happens with dtmfmode set 2833 of info.
Comments:By: Asterisk Team (asteriskteam) 2020-04-02 08:30:54.683-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].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Adrien Martin (AdrienMartin) 2020-04-02 08:32:02.937-0500

Core dump added for version 16.9.0.
By: Joshua C. Colp (jcolp) 2020-04-02 08:33:47.488-0500

Thank you for the crash report. However, we need more information to investigate the crash. Please provide:

1. A backtrace generated from a core dump using the instructions provided on the Asterisk wiki [1].
2. Specific steps taken that lead to the crash.
3. All configuration information necesary to reproduce the crash.

Thanks!

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


By: Adrien Martin (AdrienMartin) 2020-04-02 10:23:17.029-0500

Ah yes sorry, attaching the backtrace files, with DONT_OPTIMIZE and BETTER_BACKTRACES compile flags.

About specific steps I don't really know what is relevant.
The system is installed on debian stretch.
The UAC are linphone and zoiper either directly or with an old asterisk between.

Added the configuration files too.
There is an empty pjproject.conf file too.
By: Sean Bright (seanbright) 2020-04-02 10:40:22.514-0500

You should load a timer. In modules.conf:

{noformat}
load = res_timing_timerfd.so
{noformat}

Asterisk still shouldn't crash though.
By: Adrien Martin (AdrienMartin) 2020-04-02 10:57:14.377-0500

Thanks the crash does not occur with this module.

I should review all of our modules loading and retry autoload.
By: Benjamin Keith Ford (bford) 2020-04-02 12:57:43.172-0500

I've opened a ticket to investigate this.
By: Tim Steiner (tsteiner) 2020-05-11 18:26:59.152-0500

I've experienced this issue in 13.33.0 as well.  Please update the list of affected versions.  Thanks!
Loading the timer module eliminated the crash for me as well.
By: Mark Murawski (kobaz) 2020-11-12 19:41:31.592-0600

pbs-sbc*CLI> module load res_timing_timerfd.so
Loaded res_timing_timerfd.so

Confirmed to fix the issue
By: Mark Murawski (kobaz) 2020-11-12 19:58:23.472-0600

Attached patch -- Fixes this crash when no timer module is loaded
By: Sebastian Kemper (skemper) 2020-12-24 14:02:37.496-0600

Merry Christmas,

We have a bug open now for this as well: https://github.com/openwrt/telephony/issues/597

I did a git-bisect in branch "16" between ca. 16.3.0 and the last commit in "16". It turned up with commit: 43d4c0e3c9ac27ea0b3cd49085e72465b63e3014 "channel.c: Resolve issue with receiving SIP INFO packets for DTMF". Without this commit there is no segfault. Loading timerfd module works, too.

I did a backtrace, but I'm not really knowledgeable when it comes to BTs, so I'll just post it here, maybe it helps, maybe it doesn't.

Thread 2 "asterisk" received signal SIGSEGV, Segmentation fault.
ast_timer_set_rate (handle=0x0, rate=rate@entry=50) at timing.c:168
168 return handle->holder->iface->timer_set_rate(handle->data, rate);
(gdb) bt
#0  ast_timer_set_rate (handle=0x0, rate=rate@entry=50) at timing.c:168
#1  0x00469ae7 in __ast_read (chan=0x6a62b8, dropaudio=dropaudio@entry=0, dropnondefault=dropnondefault@entry=0) at channel.c:3952
#2  0x0046a88f in ast_read_stream (chan=<optimized out>) at channel.c:4278
#3  0x0045598d in bridge_handle_trip (bridge_channel=0x6fae08) at bridge_channel.c:2623
#4  bridge_channel_wait (bridge_channel=0x6fae08) at bridge_channel.c:2838
#5  bridge_channel_internal_join (bridge_channel=bridge_channel@entry=0x6fae08) at bridge_channel.c:2989
#6  0x00449651 in ast_bridge_join (bridge=bridge@entry=0x6a8518, chan=chan@entry=0x6a62b8, swap=swap@entry=0x0, features=features@entry=0x77872700,
   tech_args=tech_args@entry=0x0, flags=flags@entry=(AST_BRIDGE_JOIN_PASS_REFERENCE | AST_BRIDGE_JOIN_INHIBIT_JOIN_COLP)) at bridge.c:1725
#7  0x00500d5b in ast_bridge_call_with_flags (warning: GDB can't find the start of the function at 0x77041114.

   GDB is unable to find the start of the function at 0x77041114
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
   This problem is most likely caused by an invalid program counter or
stack pointer.
   However, if you think GDB should simply search farther back
from 0x77041114 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
chan=0x6a62b8, peer=<optimized out>, config=<optimized out>, flags=flags@entry=0) at features.c:679
#8  0x00500dbd in ast_bridge_call (chan=<optimized out>, peer=<optimized out>, config=<optimized out>) at features.c:718
#9  0x77041115 in ?? ()
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) q

Best regards,
Seb