[Home]

Summary:ASTERISK-26721: Asterisk Crash - astobj2.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7fc9f402d088
Reporter:Félim Whiteley (felimwhiteley)Labels:
Date Opened:2017-01-16 10:18:11.000-0600Date Closed:2020-01-14 11:14:10.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Addons/General
Versions:13.11.2 13.13.1 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:- Ubuntu 14.04 - HP ProLiant DL380 Gen G7 - Digium, Inc. Wildcard TE820 octal-span T1/E1/J1 card 3.3V (PCI-Express) (rev 02)Attachments:( 0) 2017-01-16-104349-asterisk_debug.txt
( 1) 2017-01-16-104410-asterisk_debug.txt
( 2) 2017-01-16-104528-asterisk_debug.txt
Description:Under low or high load the server starts to get high CPU usage and call quality drops until the box becomes unusable. It's a production server so hard to run traces on as usually it occurs when there are a large amount of calls.

I compiled in the DEBUG options from the troubleshooting guide and have attached a trace. The server had not fully crashed by this point but asterisk process was filling approximately 8 cores on the server at 100%. The only fix is a core restart.

I can't recreate it but it happens almost every day, to alleviate the issue a graceful restart is scheduled each day during a known low call period, the box is required 24/7.

Upgraded to 13.13.1 as an attempt to fix but still occurring.
Comments:By: Asterisk Team (asteriskteam) 2017-01-16 10:18:12.247-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].
By: Joshua C. Colp (jcolp) 2017-01-17 10:06:48.496-0600

What is the console output? What is going on on the system (recording? playbacks? bridges? queues?).
By: Félim Whiteley (felimwhiteley) 2017-01-17 10:24:33.520-0600

Ok that would have been helpful (rushing for a flight - apologies). The simple answer is yes. All of that. In fairness this never got to the point of actual error message above, but that happened earlier in same condition. Callers were reporting inability to hear IVR files, agents could not hear agents clearly. Without performing a graceful restart it will happen within a 24hr period and sometimes more than once. I can provide console logs in debug but not in public.

It seems to have started after 13.1, we had to move from 13.1 because of the bug where remote SIP trunks going offline could take down the other server. ASTERISK-24635

One unusual factor is a separate server with similar hardware (albeit different generation of machine with only a quad card) but exact OS/Asterisk version has never had any issue, but does not get anywhere near the load.
By: Joshua C. Colp (jcolp) 2017-01-17 10:30:22.774-0600

I think we'll still need more details if we have any hope of figuring this out.
By: Asterisk Team (asteriskteam) 2017-02-01 12:00:01.440-0600

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