| Summary: | ASTERISK-26877: app_queue: Crash when seeing if a member can be rung | ||||
| Reporter: | Kevin Farrell (kfpelletier) | Labels: | |||
| Date Opened: | 2017-03-15 08:13:09 | Date Closed: | 2020-01-14 11:14:05.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Applications/app_queue | ||
| Versions: | 13.13.1 | Frequency of Occurrence | Frequent | ||
| Related Issues: |
| ||||
| Environment: | Centos 6.7 64bit | Attachments: | ( 0) asterisk.txt ( 1) backtrace.txt ( 2) core.zip ( 3) modules.txt ( 4) modules2.txt | ||
| Description: | Hi,
I am getting Core Dumps which, when generated, drop all concurrent calls. I have tried recompiling Asterisk to three different version; 13.0.0, 13.13.1 and am now on 13-cert. In all cases, the same kind of message is generated by the core dump. Here is a copy of the message: Program terminated with signal 11, Segmentation fault. #0 0x00007fe9fc4a44d7 in can_ring_entry (qe=0x7fe9f471e2e0, tmp=0x7fea3c25ba10, busies=0x7fe9f471e1d4) at app_queue.c:4167 4167 if (call->member->in_call && call->lastqueue->wrapuptime) { I hope you can recommend a resolution to this problem; any help would be greatly appreciated. Please do not hesitate to ask me for some more information as I would gladly provide it. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-03-15 08:13:10.035-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) 2017-03-15 08:18:52.139-0500 Please provide the specific version that matches the backtrace. I've gone through various versions and can't match the line number. The issue should already be fixed in later versions though. By: Kevin Farrell (kfpelletier) 2017-03-15 08:21:37.675-0500 Hi, I am currently running 13.13-cert1. However, I have tried with 13.13.1 and have been getting the same results. By: Joshua C. Colp (jcolp) 2017-03-15 08:25:33.283-0500 Certified only receives changes as a result of issues from support agreement customers. I'd suggest using the latest version of 13 and providing a backtrace of the crash from that. As it is the backtrace you've provided does NOT have the fix for the crash. By: Kevin Farrell (kfpelletier) 2017-03-15 08:30:55.826-0500 Hi, I was under the impression that the certified version would contain less crash bugs (my bad !). I will recompile to latest 13.13.x version and submit a new report if I get crashes. Thank you very much for your time ! By: Kevin Farrell (kfpelletier) 2017-03-20 07:53:50.747-0500 Hi, I have recompiled Asterisk to 13.13.1. I get the same problem. I will attach the full Core Dump to this Report. This type of crash that happens often, and I believe it has something to do with inbound calls going to app_queue and then crashing when checking for available agents. By: Kevin Farrell (kfpelletier) 2017-03-20 07:57:34.187-0500 This is the Core Dump file. By: Joshua C. Colp (jcolp) 2017-03-20 08:10:49.959-0500 The core dump is not useful except on the system itself. You need to follow the instructions on the wiki[1] to get a backtrace from it. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationAfterACrash By: Kevin Farrell (kfpelletier) 2017-03-20 08:19:33.381-0500 Hi, Sorry about that, here is the backtrace you requested. By: Joshua C. Colp (jcolp) 2017-03-20 08:30:45.501-0500 The backtrace shows this line: {noformat} if (call->member->in_call && call->lastqueue->wrapuptime) { {noformat} Which does not exist in Asterisk 13.13.1. What is the output of "core show version" from the Asterisk CLI? By: Kevin Farrell (kfpelletier) 2017-03-20 08:33:44.111-0500 Here is the output: "Asterisk 13.13.1 built by root @ connextek on a x86_64 running Linux on 2017-03- 02 17:26:16 UTC" Please do not hesitate to ask if you require further information; I will gladly provide it. Thank you for your time. By: Joshua C. Colp (jcolp) 2017-03-20 08:37:54.231-0500 I'm very confused then since the backtrace clearly shows a bug (and code) that has already been fixed in 13.13.1. Did you make any modifications to the source code? By: Kevin Farrell (kfpelletier) 2017-03-20 08:41:22.895-0500 Hi, I did not alter the source code in any way; I compiled Asterisk from source a bunch of times on the server, so maybe this had an impact on the code? Also, I run a FreePBX GUI over Asterisk, so maybe therein lies the issue? By: Kevin Farrell (kfpelletier) 2017-03-20 14:41:12.277-0500 I have a different client who uses app_queue a lot more. He is on 13.8.2. Today, his PBX generated around 20 Core Dumps, cutting all his calls at once every single time. By: Joshua C. Colp (jcolp) 2017-03-20 18:52:33.709-0500 Can you please attach the output of "ls -al /usr/lib/asterisk/modules" and "ls -al /usr/sbin/asterisk"? By: Kevin Farrell (kfpelletier) 2017-03-21 07:06:42.720-0500 Here is the output for the commands you requested. I executed them on the 13.13.1 PBX By: Joshua C. Colp (jcolp) 2017-03-21 07:14:28.185-0500 Wait a second... you've got two Asterisk installs installed. Looking at the backtrace again shows it pulling modules from /usr/lib64/asterisk/modules/ - if those are the old ones it would explain what is going on. Asterisk may be loading from there, and they may be old. What's the output of "ls -al /usr/lib64/asterisk/modules" from there? [~gjoseph] Thoughts? By: Kevin Farrell (kfpelletier) 2017-03-21 07:18:41.185-0500 Hi, Here is the required output By: George Joseph (gjoseph) 2017-03-21 07:51:17.162-0500 Yeah, All RedHat based 64-bit systems use /usr/lib64 but autoconf doesn't detect it correctly in order distros. If you install from packages, it's corrected though so at some point you must have installed from packages and installed from source. I'd do the following... - Backup your config. - Run 'yum erase asterisk*' and make sure that /usr/lib64/asterisk and /usr/lib64/libasterisk* are gone. Remove them manually if not. - From your asterisk source directory, run 'make uninstall' and make sure that /usr/lib/asterisk and /usr/lib/libasterisk* are gone. Remove them manually if not. - Reconfigure asterisk with './configure --prefix=/usr --libdir=/usr/lib64' and any other options you normally use then 'make'. - Run 'make install' - Check /etc/asterisk/asterisk.conf and make sure 'astmoddir' points to /usr/lib64/asterisk/modules. By: Kevin Farrell (kfpelletier) 2017-03-21 08:18:30.973-0500 Hi George, I will give this a try tonight and get back to you tomorrow. Thank you for the insight By: Asterisk Team (asteriskteam) 2017-04-04 12:00:01.265-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 | ||||