| Summary: | ASTERISK-27141: Asterisk crashes when applying freePBX config | ||
| Reporter: | Andrey Prokofyev (kashak) | Labels: | |
| Date Opened: | 2017-07-18 09:33:31 | Date Closed: | |
| Priority: | Major | Regression? | Yes |
| Status: | Open/New | Components: | Core/Configuration |
| Versions: | 13.16.0 13.17.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Ubuntu 16.04.2 LTS 4.4.0-83-generic #106-Ubuntu 2vCPU, 4GB RAM FreePBX 13.0.192.9 PHP 5.6.31-1~ubuntu16.04.1+deb.sury.org+1 dahdi-linux-complete-2.11.1 libpri-1.6.0 Makemenu custom modules: format_mp3, res_config_mysql, app_mysql, cdr_mysql, app_meetme, CORE-SOUNDS-EN-GSM, EXTRA-SOUNDS-EN-GSM | Attachments: | ( 0) asterisk-ASTERISK-27141-results.tar.gz ( 1) valgrind.txt |
| Description: | Hello,
We build asterisk from source. Up until version 13.16.0 things operated smoothly. When we tried 13.16.0 and more recently 13.17.0, applying freepbx config from GUI would crash asterisk and produce core dump. Reverting back to 13.15.1 solves this problem. I'm attaching the latest core dump from the recent 13.17.0 upgrade we tried a couple of days ago. One of our sys admins created a new conference line and applied config. All the phones in the office experienced a few seconds of outage and server LA got as high as 14, compared to the usual 0.2 - 0.4. Please let me know if anything else is needed | ||
| Comments: | By: Asterisk Team (asteriskteam) 2017-07-18 09:33:32.850-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: Richard Mudgett (rmudgett) 2017-07-18 09:46:59.010-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 Sorry. The backtraces you have provided have no symbol information and cannot be used. By: Andrey Prokofyev (kashak) 2017-07-19 22:40:18.063-0500 Hello, I've attached the new backtrace. Please let me know if this is sufficient By: Richard Mudgett (rmudgett) 2017-07-20 11:45:00.954-0500 Your backtrace appears to contain a memory corruption. We need one or both of the following items to continue investigation of the issue: 1. Valgrind output. See https://wiki.asterisk.org/wiki/display/AST/Valgrind for instructions on how to use Valgrind with Asterisk. 2. MALLOC_DEBUG output. See https://wiki.asterisk.org/wiki/display/AST/MALLOC_DEBUG+Compiler+Flag for instructions on how to use the MALLOC_DEBUG option. Note that MALLOC_DEBUG and Valgrind are mutually exclusive options. Valgrind output is preferable, but will be more system resource intensive and may be difficult to get on a production system. In such a case, you may have better luck getting the necessary output from MALLOC_DEBUG. The backtrace has symbols this time which is good. However, the attached backtrace is showing a crash in the memory allocator. This is a sure sign that memory corruption has happened. By: Andrey Prokofyev (kashak) 2017-07-20 12:13:27.002-0500 Hi Richard, I'll get the valgrind output this evening when there are no active users. Our production system is a VM so I could assign as many resources as needed. What would be the preferred vCPU and RAM values? Thanks By: Richard Mudgett (rmudgett) 2017-07-20 12:19:04.362-0500 Valgrind is more CPU intensive than memory hungry. I read somewhere that valgrind causes a 30 times slowdown to the executing program. By: Andrey Prokofyev (kashak) 2017-07-20 19:53:15.268-0500 valgrind results are attached. Took 4 tries to finally get the process "killed". The steps were basically the same - Conferences -> delete one -> apply config Thanks | ||