[asterisk-users] Asterisk won't start - trap invalid opcode

Duncan Turnbull duncan at e-simple.co.nz
Wed Jan 4 07:20:08 CST 2012


I loaded the latest 1.6 which gets slightly further and a core dump shows this, but its past my ability to interpret

# gdb -se "asterisk" -c core | tee /tmp/backtrace.txt
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/sbin/asterisk...done.
[New LWP 19322]
[New LWP 19323]
[New LWP 19324]
[New LWP 19325]
[New LWP 19326]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Core was generated by `asterisk -d -g -cvvvvvvvvvvvvvvvvvvv'.
Program terminated with signal 4, Illegal instruction.
#0  0x0000000000500eab in tzload (name=<optimized out>, sp=0x1fc7950, doextend=1) at stdtime/localtime.c:424
424	static int tzload(const char *name, struct state * const sp, const int doextend)



On 5/01/2012, at 12:13 AM, Duncan Turnbull wrote:

> On 4/01/2012, at 11:47 PM, A J Stiles wrote:
> 
> 
>> 
>> For what it's worth, I once tried installing Asterisk on an old VIA C7 box; 
>> and it turns out that this processor, while detecting as an i686, doesn't 
>> implement the full i686 instruction set -- and Asterisk is trying to use one 
>> of the non-implemented instructions.  Solution was to re-compile for i586.
>> 
> 
> Thanks very much AJ
> 
> That did appear as one of the few google comments I found but I couldn't figure out whether it applies 
> 
> The outputs are below if you can interpret them, I can see lm in the cpu proc info but don't know how to check for better compatibility
> 
>> It's just possible that something similar is going on here -- maybe your 
>> processor isn't implementing an instruction that Asterisk or Dahdi is relying 
>> on.  (It's my understanding that 64-bit processors don't fully implement the 
>> 32-bit instructions when in 64-bit mode, but I wouldn't swear to that.)  Or 
>> maybe it's a library path problem -- something trying to use a 32-bit library 
>> instead of a 64-bit one, or vice versa.  Try ldd on the binaries.
>> 
> ldd -v /usr/sbin/asterisk 
> 	linux-vdso.so.1 =>  (0x00007fff407ff000)
> 	libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f72accc0000)
> 	libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f72ac911000)
> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f72ac571000)
> 	libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00007f72ac216000)
> 	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f72ac012000)
> 	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f72abdf4000)
> 	libtinfo.so.5 => /lib/libtinfo.so.5 (0x00007f72abbcd000)
> 	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f72ab949000)
> 	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f72ab72d000)
> 	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f72ab515000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007f72acf1b000)
> 
> 	Version information:
> 	/usr/sbin/asterisk:
> 		libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
> 		libresolv.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libresolv.so.2
> 		libxml2.so.2 (LIBXML2_2.6.0) => /usr/lib/libxml2.so.2
> 		libxml2.so.2 (LIBXML2_2.4.30) => /usr/lib/libxml2.so.2
> 		libcrypto.so.1.0.0 (OPENSSL_1.0.0) => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> 		libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
> 		libpthread.so.0 (GLIBC_2.3.3) => /lib/x86_64-linux-gnu/libpthread.so.0
> 		libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0
> 		libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libssl.so.1.0.0 (OPENSSL_1.0.0) => /lib/x86_64-linux-gnu/libssl.so.1.0.0
> 	/lib/x86_64-linux-gnu/libssl.so.1.0.0:
> 		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 		libcrypto.so.1.0.0 (OPENSSL_1.0.0) => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> 	/lib/x86_64-linux-gnu/libcrypto.so.1.0.0:
> 		libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
> 		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
> 	/lib/x86_64-linux-gnu/libc.so.6:
> 		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
> 		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
> 	/usr/lib/libxml2.so.2:
> 		libz.so.1 (ZLIB_1.2.2.3) => /lib/x86_64-linux-gnu/libz.so.1
> 		libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
> 		libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
> 		libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
> 	/lib/x86_64-linux-gnu/libdl.so.2:
> 		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
> 		libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 	/lib/x86_64-linux-gnu/libpthread.so.0:
> 		ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
> 		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
> 		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
> 		libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 	/lib/libtinfo.so.5:
> 		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 	/lib/x86_64-linux-gnu/libm.so.6:
> 		libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 	/lib/x86_64-linux-gnu/libresolv.so.2:
> 		libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
> 	/lib/x86_64-linux-gnu/libz.so.1:
> 		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
> 		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
> 
>> What is your output from `cat /proc/cpuinfo` ?
>> 
> # cat /proc/cpuinfo 
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 15
> model		: 4
> model name	: Intel(R) Pentium(R) 4 CPU 3.06GHz
> stepping	: 9
> cpu MHz		: 3058.891
> cache size	: 1024 KB
> physical id	: 0
> siblings	: 1
> core id		: 0
> cpu cores	: 1
> apicid		: 0
> initial apicid	: 0
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 5
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc up pebs bts nopl pni dtes64 monitor ds_cpl tm2 cid cx16 xtpr lahf_lm
> bogomips	: 6117.78
> clflush size	: 64
> cache_alignment	: 128
> address sizes	: 36 bits physical, 48 bits virtual
> power management:
>> 
>> If you have at least two SIP phones and/or an IAX route, try disabling Dahdi, 
>> and see if you can persuade Asterisk to run like that.  At least that should 
>> help track the problem down to one layer (Asterisk or Dahdi).
> 
> Unfortunately it dies with this error just trying to start asterisk - whether with dahdi and /or wanpipe on or off
> 
> I am now wondering about the sangoma wanpipe driver and this same point, but I am not sure how to force it to be 32 bit 
> 
> 
>> 
>> -- 
>> AJS
>> 
>> Answers come *after* questions.
>> 
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>              http://www.asterisk.org/hello
>> 
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>  http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users




More information about the asterisk-users mailing list