Asterisk 1.6 crashes with Asterisk-GUI 2.0

Asterisk Asterisk Support
1

Thanks for helpful information on that topic in advance!

What I did is upgrading from Asterisk 1.4.22.2 to Asterisk 1.6.1.6. Before that, Asterisk-GUI was working just fine.
The Asterisk-GUI is SVN Rev. 4986 (most current). Asterisk is listening on the default port 8088, a netstat -l is confirming this.

Everytime I access the GUI by myip:8088/static/config/index.html, the asterisk process crashes without any indications on the CLI (not even on verbose 100, debug 100). The only log entry i can find is a segfault in syslog messages:

~# tail -1 /var/log/messages
Oct 13 15:14:59 VoIPcom10-installer kernel: asterisk[6805]: segfault at b71788e0 eip 08116dd0 esp b71788c0 error 6

nothing in Asterisk log:

~# tail -1 /var/log/asterisk/messages
~#

segfault in CLI:

~# /usr/sbin/asterisk -vvvvvv -g  -dddddd -c
*CLI> Segmentation fault (core dumped)
  • configuration: -

my http.conf:

~# cat /etc/asterisk/http.conf
[general]
enabled=yes
enablestatic=yes
bindaddr=0.0.0.0
bindport=8088

my manager.conf:

[code]
~# cat /etc/asterisk/manager.conf
[general]
enabled = yes
webenabled = yes
port = 5038
bindaddr = 0.0.0.0
debug = on ; enable some debugging info in AMI messages (default off).

[admin]
secret = whatever
read = system,call,log,verbose,command,agent,config
write = system,call,log,verbose,command,agent,config[/code]

any ideas?

2

See http://svn.digium.com/svn/asterisk/tags/1.6.1.6/doc/backtrace.txt

3

tzload in stdtime/localtime.c doesnt make a lot of sense to me…

Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  0x08125d4b in tzload (name=0x8173667 "GMT", sp=0x827f298, doextend=1) at stdtime/localtime.c:292
292    if ((strlen(p) + strlen(name) + 1) >= sizeof fullname)
(gdb) bt full
#0  0x08125d4b in tzload (name=0x8173667 "GMT", sp=0x827f298, doextend=1) at stdtime/localtime.c:292
 doaccess = 0
 fullname = Cannot access memory at address 0xb70c07dc
(gdb) quit

i submitted a bug report:
issues.asterisk.org/view.php?id=16065

4

It’s a local copy of tzload. fullname is an array, on the stack, so something has to be bad with the stack, or hardware, to get it to produce a bad address.

5

this morning i figured it works just fine without any coredumps as long as the compiler flag “LOW_MEMORY” is disabled.