Summary:	ASTERISK-28307: Segmentation fault in libasteriskpj.so.2
Reporter:	Joseph Hayhoe (jhayhoe)	Labels:	pjsip
Date Opened:	2019-02-26 10:33:30.000-0600	Date Closed:	2020-01-14 11:14:11.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	General
Versions:	13.22.0	Frequency of Occurrence	One Time
Related Issues:
Environment:	Sangoma Linux release 7.5.1805 FreePBX 14.0.5.25	Attachments:	( 0) core.dc3-freepbx1.int.liquidweb.com-2019-02-26T00-37-57+0000-brief.txt ( 1) core.dc3-freepbx1.int.liquidweb.com-2019-02-26T00-37-57+0000-full.txt ( 2) core.dc3-freepbx1.int.liquidweb.com-2019-02-26T00-37-57+0000-locks.txt ( 3) core.dc3-freepbx1.int.liquidweb.com-2019-02-26T00-37-57+0000-thread1.txt ( 4) core.dc3-freepbx1.int.liquidweb.com-2019-02-26T16-41-08+0000-brief.txt ( 5) core.dc3-freepbx1.int.liquidweb.com-2019-02-26T16-41-08+0000-full.txt ( 6) core.dc3-freepbx1.int.liquidweb.com-2019-02-26T16-41-08+0000-locks.txt ( 7) core.dc3-freepbx1.int.liquidweb.com-2019-02-26T16-41-08+0000-thread1.txt
Description:	Last night we experienced a segmentation fault on the server during normal operation: kernel: asterisk[30994]: segfault at 18 ip 00007f76bb1bbc54 sp 00007f75dbeb0c50 error 4 in libasteriskpj.so.2[7f76bb092000+17f000] We did recently add the Digium Phone module to asterisk via res_digium_phone.so. This module was loaded but was pending a restart of Asterisk. There were no errors reported in the asterisk full log at the time of the crash. I have and will attach the processed crashdump to this issue momentarily.
Comments:	By: Asterisk Team (asteriskteam) 2019-02-26 10:33:31.131-0600 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: Joseph Hayhoe (jhayhoe) 2019-02-26 10:37:38.428-0600 Core dumps By: Joshua C. Colp (jcolp) 2019-02-26 10:42:54.169-0600 Please upgrade to the latest version, there have been fixes in this area which may have resolved the underlying problem. Specifically Teluu uncovered a bug which could cause double frees in these cases, resulting in crashes. By: Joseph Hayhoe (jhayhoe) 2019-02-26 10:59:03.672-0600 Upgrade to the latest version of Asterisk or the lastest version of res_digium_phone.so? By: Joshua C. Colp (jcolp) 2019-02-26 11:04:15.017-0600 The crash occurred in PJSIP in the core of the stack, it's unrelated to res_digium_phone and upgrading res_digium_phone would not alter it. Upgrading to the latest Asterisk (and by extension bundled PJSIP) is what I meant. By: Joseph Hayhoe (jhayhoe) 2019-02-26 12:25:32.377-0600 Looks like currently FreePBX does not offer a newer build of Asterisk other than 13.22.0 in their repo's. Could this issue be related to the res_digium_phone module that was installed not being the module for the -bundled version of pjsip? Is there a way to confirm if Asterisk is using the bundled pjsip over a separate build of pjsip? By: Joshua C. Colp (jcolp) 2019-02-26 13:20:37.959-0600 The res_digium_phone module does not use or access PJSIP in this fashion. The fact it's bundled or not should not matter with recent versions of DPMA, and if there were a problem it would either not load or the backtrace would be vastly different. It is using bundled as the filename for the pjproject library is "libasteriskpj.so" By: Joseph Hayhoe (jhayhoe) 2019-02-26 13:47:57.345-0600 We witnessed another crash of Asterisk today and I have included those core dump files in this card 2019-02-26T16-41-08. The digium phone module also depends on the following module: res_pjsip_endpoint_identifier_dpma.so This is bundled in the same yum package installed for digium phone support. Could that be in any way related to the crashes of pjsip? By: Joshua C. Colp (jcolp) 2019-02-26 13:52:40.754-0600 No, it's not related to DPMA. The crash itself is in the RTP layer - specifically ICE/STUN/TURN support, so if WebRTC (Zulu or something else) is in use then that would be what is causing the code to be executed. By: Joseph Hayhoe (jhayhoe) 2019-02-26 16:12:35.792-0600 We do use WebRTC for our primary phone application developed using JsSIP. We are not using STUN/TURN as we are routing our phone network internally and through our VPN for remote agents (not NAT traversal). By: Joshua C. Colp (jcolp) 2019-02-28 05:09:37.809-0600 Putting back into feedback until this can be tested and tried against current version. If this auto-closes and you need to reopen it, just commenting will do so. By: Asterisk Team (asteriskteam) 2019-03-14 12:00:01.613-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