Summary:	ASTERISK-27753: bridge: Crash when freeing after bridge data after transfer occurs
Reporter:	Olivier Krief (okrief)	Labels:
Date Opened:	2018-03-20 10:47:34	Date Closed:	2020-01-14 11:13:29.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	General
Versions:	13.19.0	Frequency of Occurrence	Occasional
Related Issues:
Environment:	Debian Stretch on VMWare. Asterisk compiled from source.	Attachments:	( 0) core-brief.txt ( 1) core-full.txt ( 2) core-locks.txt ( 3) core-thread1.txt ( 4) full ( 5) syslog
Description:	From time to time (once every two months or so), Asterisk exits with segfault without prior error message. Log file includes both lines bellow (and nothing between them): [2018-03-20 15:48:01] VERBOSE[4893][C-0005a469] pbx.c: Spawn extension (from-Foobar, 0326473958, 1) exited non-zero on 'SIP/Foobar2-000b649e' [2018-03-20 15:49:49] Asterisk 13.19.0 built by root @ Sipaccess-prod_2 on a x86_64 running Linux on 2018-02-08 23:12:35 UTC Lastest line shows Asterisk exited without being required to. I would expect Asterisk not to exit even if being mis-configured.
Comments:	By: Asterisk Team (asteriskteam) 2018-03-20 10:47:35.846-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 C. Colp (jcolp) 2018-03-26 09:48:54.445-0500 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected and the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information In this specific case we need to know what was going on at the time and how Asterisk is being used. By: Olivier Krief (okrief) 2018-03-26 15:06:08.881-0500 1. Asterisk restart was probably triggered by Systemd asterisk.service "Restart=on-failure" setting. 2. The machine that re-started produces SIP trunking services using chan_sip (100-150 simultaneous calls). Dialplan is very basic. 3. How can I attach a log file and keep it private ? By: Joshua C. Colp (jcolp) 2018-03-26 17:01:04.175-0500 We only accept private logs in certain cases, we ask that reporters sanitize them as they need. By: Olivier Krief (okrief) 2018-03-27 11:53:31.652-0500 Anonymized log file By: Olivier Krief (okrief) 2018-03-27 12:26:44.814-0500 In attached full file, both lines are present: [2018-03-20 15:48:01] VERBOSE[4893][C-0005a469] pbx.c: Spawn extension (from-Bob, 0326473958, 1) exited non-zero on 'SIP/Bob2-000b649e' [2018-03-20 15:49:49] Asterisk 13.19.0 built by root @ Sipaccess-prod_2 on a x86_64 running Linux on 2018-02-08 23:12:35 UTC I also attached a syslog file as root cause maight come from VMWare environment. Shall I gather more data ? (Please, do not hesitate to ask as I'm really willing to understand what happened) Is there a guide somewhere I could use to analyze data in core-*.txt files ? If not, is there something I can do to be reasonably sure that next time,  I will have an idea on the specific steps or actions  that can cause the present issue ? By: Joshua C. Colp (jcolp) 2018-03-28 05:13:13.033-0500 Was this Asterisk built with DONT_OPTIMIZE[1]? The backtrace has a lot of data optimized out which makes it hard to piece together what was happening where. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: Olivier Krief (okrief) 2018-03-29 02:37:38.281-0500 Yes, you are right : I had a bug in my installation script that kept DONT_OPTIMIZE and BETTER_BACKTRACES options from being set ! I feel really sorry and ashamed about that ! Given current data, would you recommend to log anything special, beside Asterisk log files and syslog ? Current asterisk.conf content is: [options] verbose = 5 maxfiles = 40960 Shall I set DEBUG, for instance ? By: Joshua C. Colp (jcolp) 2018-03-29 04:25:05.707-0500 DEBUG level output would be helpful in seeing what the specific channel was up to, so if you can provide it then that would be good as well. By: Olivier Krief (okrief) 2018-03-29 08:26:45.973-0500 I am are planning to change, in 7 hours from now, my machine settings: with DEBUG level set to 5 with DONT_OPTIMIZE and BETTER_BACKTRACES compiler flags. Usually, it segfaults every two monthes or so. What kind of feedback is waited from me now ? Shall I wait for next issue to happen and then update core and log files with fresh ones ? By: Joshua C. Colp (jcolp) 2018-03-29 08:29:39.046-0500 Yes, with an optimized build the information is limited so this can't progress any further. Once you have that information you can provide it here. The issue will likely auto-close but it'll reopen automatically then. By: Asterisk Team (asteriskteam) 2018-04-12 12:00:01.563-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