[Home]

Summary:ASTERISK-23835: crash: Segfault in manager during lookup of action "Login" in action_find
Reporter:Matteo (mpiazzatnetbug)Labels:
Date Opened:2014-06-09 04:04:05Date Closed:2014-07-25 17:54:17
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:11.2.2 Frequency of
Occurrence		One Time
Related
Issues:
Environment:Debian 6.0.7 virtualized on Proxmox 3.1 (KVM) Memory 1Gb CPU 2.27 GHz (1 socket)Attachments:( 0) backtrace_better.txt
( 1) backtrace.txt
Description:Segfault of asterisk

An external process is connected with the manager interface to monitor the peer status and execute click to dial function.

last week after more than 60 days the asterisk process goes into a segfault.

from the backtrace seems link to action_find in manager.c


Comments:By: Matt Jordan (mjordan) 2014-06-09 06:34:27.497-0500

# The backtrace has a number of optimized symbols stripped out of it. That will make determining why the lookup for the AMI action caused a seg fault difficult. Please attach a backtrace generated from an instance of Asterisk with {{DONT_OPTIMIZE}} and {{BETTER_BACKTRACES}} enabled.
# If you have the core file still, and symbols are present, open it up in gdb ({{gdb -se asterisk -c core}} - and print the values of the following:
** {{frame 0}}
** {{print *actions}}
** {{print *act}}
** {{print *act->action}}

By: Matteo (mpiazzatnetbug) 2014-06-09 08:23:48.286-0500

As attachment a backtrace_better.txt file with DONT_OPTIMIZE enable.

additional info:
manager.conf file:

[infoasterisk]
secret=info47sDz




By: Matt Jordan (mjordan) 2014-06-09 08:40:26.153-0500

Looking at your most recent backtrace:

{noformat}
Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  0xb76e2652 in ?? ()
#0  0xb76e2652 in ?? ()
No symbol table info available.
#1  0x0815406f in named_acl_find_realtime (
   name=0xc80fdd0 "\r\ncret: info47sDz\r\n\r\nk\r\nSecret: info47sDz\r\n\r\nrisk\r\nSecret: info47sDz\r\n\r\n: info47sDz\r\n\r\n") at named_acl.c:271
       cfg = 0x0
       item = 0xadd86aef ""
       systemname = 0x12 <Address 0x12 out of bounds>
       built_ha = 0xadd86a88
       acl = 0xb76e0ec8
       __PRETTY_FUNCTION__ = "named_acl_find_realtime"
#2  0x0815776c in pbx_exec (c=0xa96494b4, app=0x0, data=0x2 <Address 0x2 out of bounds>) at pbx.c:1579
       res = 1401750001
       u = 0x538d01f1
       saved_c_appl = 0x1 <Address 0x1 out of bounds>
       saved_c_data = 0x0
       __PRETTY_FUNCTION__ = "pbx_exec"
#3  0x081b28bd in ast_translator_deactivate (t=0xa96494b4) at translate.c:1184
       __PRETTY_FUNCTION__ = "ast_translator_deactivate"
#4  0x081bfcc5 in xmldoc_parse_variablelist (node=0xa9cef8c0, tabs=0xadd87b70 "p{ح@ۿ\260p{ح\001", buffer=0xadd87b70) at xmldoc.c:1538
       tmp = 0xadd87394
       varname = 0xb77b0ff4 "|-\024"
       vartabs = 0x0
       ret = -1221613690
       __PRETTY_FUNCTION__ = "xmldoc_parse_variablelist"
#5  0xb72fa955 in ?? ()
No symbol table info available.
#6  0xb773a1de in ?? ()
No symbol table info available.
{noformat}

# This crash is in a completely different location.
# The backtrace still has symbols optimized out of it.

The biggest problem is point #1. You seem to have a variety of problems going on here, and I'm not sure it is related at all to manager.

Based on the sporadic nature of your crashes, you may have a memory corruption of some sort occurring. Try profiling Asterisk under valgrind - see [https://wiki.asterisk.org/wiki/display/AST/Valgrind] for information on running Asterisk under valgrind.
By: Corey Farrell (coreyfarrell) 2014-06-09 21:14:30.200-0500

This bug report states that you are running 11.2.2.  This is over a year old, I recommend you upgrade to the the most recent 11.x (currently 11.10.0).  Many bugs have been fixed in the past year, including many crashes, memory leaks and even some security vulnerabilities - even without this crash you should update.
By: Matteo (mpiazzatnetbug) 2014-06-25 07:15:56.505-0500

Since the sporadic nature and the machine is a production enviroment i prefer do not run in this case asterisk under valgrind.


By: Rusty Newton (rnewton) 2014-07-09 14:36:32.925-0500

[~mpiazzatnetbug] Please test with the latest 11 release and report back with backtraces from that. Can you get the output generated with the MALLOC_DEBUG compilation option as an alternative to running under valgrind?
By: Matteo (mpiazzatnetbug) 2014-07-10 03:17:20.855-0500

I see an issue here. Due ASTERISK-22851 from 11.6 version it's not possible run asterisk with the debug flags enable. If I upgrade and run asterisk with the debug flags enable my instance is going to crash surely before to replicate this specific issue.
So until ASTERISK-22851 is resolved I think will be hard upgrade the asterisk version. It's seems to me a "a dog chasing its own tail" situation.

By: Matt Jordan (mjordan) 2014-07-10 06:56:56.542-0500

Your issue is not related to a deadlock. The only thing {{DEBUG_THREADS}} does is to enable debugging of deadlock situations - it has nothing to do with your issue, and you should not be running Asterisk with {{DEBUG_THREADS}}.

Based on the backtrace you've provided, I would suspect you have something that valgrind would point out. I'd like to say that we could help diagnose and fix this problem without that, but it's unlikely to happen.

If you are unable or unwilling to run Asterisk under valgrind, then this issue will be closed out.
By: Rusty Newton (rnewton) 2014-07-25 17:54:08.853-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines