Floating point exception (SIGFPE) in 'int main () {return (0); } "

Question

I am trying to create a simple C program for two different Linux environments. On one device, the program runs fine; on another device, the program throws a floating-point exception. The program does nothing but return 0 from the main one, which makes me think that there is some incompatibility with the startup code, perhaps ABI?

The program was compiled using gcc with the following build specifications:

Using inline specifications. Target: i386-redhat-linux Configurable with: .. / configure --prefix = / usr --mandir = / usr / share / man --infodir = / usr / share / info --enable-shared --enable- threads = posix --enable-checking = release --with-system-zlib --enable -__ cxa_atexit --disable-libunwind-exceptions - enable-libgcj-multifile --enable-languages ​​= c, C ++, objc, obj-C ++, java, fortran, ada --enable-java-awt = gtk --disable-dssi --disable-plugin --with-java -home = / usr / lib / jvm / java-1.4 .2-gcj-1.4.2.0 / jre --with-cpu = generic --host = i386-redhat-linux Model Model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)

The source of the program is as follows:

int main() { return(0); } 

On a Celeron device, this program generates the following under GDB:

 [root@n00200C30AA2F jrn]# /jrn/gdb fail GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) (gdb) run Starting program: /jrn/fail Program received signal SIGFPE, Arithmetic exception. 0x40001cce in ?? () (gdb) bt #0 0x40001cce in ?? () #1 0x4000c6b0 in ?? () #2 0x40000cb5 in ?? () 

Below are the details that I can collect to help figure out what is happening:

 CELERON: ( fails on this device ) 2.6.8 #21 Mon Oct 1 11:41:47 PDT 2007 i686 i686 i386 GNU/Linux ============ [root@n00200C30AA2F proc]# cat cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 9 model name : Intel(R) Celeron(R) M processor 600MHz stepping : 5 cpu MHz : 599.925 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe bogomips : 1179.64 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Compiled by GNU CC version 3.2.2 20030222 (Red Hat Linux 3.2.2-5). Compiled on a Linux 2.4.20 system on 2003-03-13. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk ATOM: ( works fine on this device ) 2.6.35 #25 SMP Mon Mar 12 09:02:45 PDT 2012 i686 i686 i386 GNU/Linux ========== [root@n00E04B36ECE5 ~]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Genuine Intel(R) CPU N270 @ 1.60GHz stepping : 2 cpu MHz : 1599.874 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc up arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm bogomips : 3199.74 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: GNU C Library stable release version 2.5, by Roland McGrath et al. Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44). Compiled on a Linux 2.6.9 system on 2009-09-02. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson GNU libio by Per Bothner NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio Thread-local storage support included. 

What can I do to determine what causes this problem? What about trying to statically bind to a specific version of libc?

After a crash in GDB, I do:

 (gdb) x/1i $eip 0x40001cce: divl 0x164(%ecx) 

 (gdb) info reg eax 0x6c994f 7117135 ecx 0x40012858 1073817688 edx 0x0 0 ebx 0x40012680 1073817216 esp 0xbffff740 0xbffff740 ebp 0xbffff898 0xbffff898 esi 0x8049580 134518144 edi 0x400125cc 1073817036 eip 0x40001cce 0x40001cce eflags 0x10246 66118 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x0 0 (gdb) x/1wx 0x164+$ecx 0x400129bc: 0x00000000 (gdb) 

Based on the help received, it appears that for some reason the libc startup code is divided by 0.

The question is what causes this obviously bad behavior? Should something be incompatible with something else?

Assembly:

 [jrn@localhost ~]$ more fail.s .file "fail.c" .text .globl main .type main, @function main: leal 4(%esp), %ecx andl $-16, %esp pushl -4(%ecx) pushl %ebp movl %esp, %ebp pushl %ecx movl $0, %eax popl %ecx popl %ebp leal -4(%ecx), %esp ret .size main, .-main .ident "GCC: (GNU) 4.1.2 20080704 (Red Hat 4.1.2-52)" .section .note.GNU-stack,"",@progbits 

Answer 1

It will sound like a very long shot ... but can you try the following?

 $ readelf -a fail 

and find the dynamic tag GNU_HASH? I assume the binary uses GNU_HASH , and your ld.so too old to understand it. Support for the GNU hash section was added to glibc around 2006, and trunk distributions became the GNU hash only in 2007 or 2008. Your Centrino glibc is from 2003, which precedes GNU hashing.

If ld.so does not understand the GNU hash, it will try to use the old ELF hash section, which is empty. In particular, I suspect that your accident occurs on this line in elf/do-lookup.h :

 for (symidx = map->l_buckets[hash % map->l_nbuckets]; 

Since the linker does not seem to understand the GNU hashes, l_nbuckets will be 0, which will lead to a crash. Note that map is a large structure with about 100 structural elements, and l_nbuckets is located around the 90th member of the structure in the new ld.so ( 0x164 = 4*89 , so this is probably this element in the earlier ld.so ) .

To verify that this is the final problem, build with -Wl,--hash-style=sysv or -Wl,--hash-style=both and see if the crash has disappeared.

Answer 2

Since it works on ATOM, but not on older Celeron, I think the problem may be in generating compiler optimization code that Celeron cannot execute. Try compiling with the -O0 flag. Also, I would suggest adding -march = i686 to explicitly specify the architecture. In addition, to help isolate the problem, I also suggest disabling communication with the C ++ and JAVA runtimes.

Did you build this test program once and run it on each device, or did you create another executable file for each device? If you are building one executable file, you may have different versions of libc, libstdc ++ on two devices or on devices against your build machine.