漂浮在'点异常（SIGFPE）INT的main（）{回报（0）; }“ [英] Floating point exception ( SIGFPE ) on 'int main(){ return(0); }'

问题描述

我想建立一个简单的C程序两种不同的Linux环境。在一个设备中的程序运行良好，其他的设备上的程序生成一个浮点异常。该方案不只是从主回0，这使我相信有一些不兼容的初创code也许ABI？

该计划是用gcc编译具有以下规格建造：

  

使用内置的规格。目标：I386-红帽Linux的配置有：
  ../configure - preFIX =的/ usr --mandir =的/ usr / share / man的
  --infodir =的/ usr /共享/信息--enable-共享--enable-线程= POSIX --enable-检查=发行--with-系统的zlib --enable -__ cxa_atexit --disable-libunwind的例外 - 使-libgcj里，多文件--enable-语言= C，C ++，objc，OBJ-C ++，JAVA，FORTRAN，ADA --enable-java的AWT = GTK --disable-DSSI --disable-插件--with-java的入户= / usr / lib目录/ JVM / JAVA-1.4.2-GCJ-1.4.2.0 / JRE --with-CPU =通用主机= I386-红帽Linux的线程模型：POSIX gcc版本4.1.2 20080704（红帽4.1.2-52）

该节目源如下：

  INT的main（）
{
        返回（0）;
}
 

在赛扬设备这一计划GDB下生成以下内容：

  [根@ n00200C30AA2F JRN]＃/ JRN / GDB失败GNU GDB的Red Hat Linux（5.3post-0.20021129.18rh）（GDB）运行启动程序：/ JRN /失败节目接收信号SIGFPE，运算异常。 0x40001cce在?? （）（GDB）BT
＃0 0x40001cce的？ （）
＃1 0x4000c6b0的？ （）
＃2 0x40000cb5的？ （）
 

下面是我能想到的收集，以帮助找到发生了什么事情的细节：

CELERON：（此设备上的失败）
2.6.8＃21星期一10月1日11时41分47秒PDT 2007 i686的的i686 i386的GNU / Linux的
============
[根@ n00200C30AA2F PROC]＃猫cpuinfo
处理器：0
VENDOR_ID：GenuineIntel
CPU系列：6
型号：9
型号名称：英特尔（R）赛扬（R）M处理器600MHz的
步进：5
CPU兆赫：599.925
缓存大小：512 KB
fdiv_bug：无
hlt_bug：无
f00f_bug：无
coma_bug：无
FPU：是
fpu_exception：是
CPUID级别：2
WP：是
标志：FPU VME德PSE TSC MSR MCE CX8月MTRR PGE MCA CMOV拍拍CLFLUSH DTS ACPI MMX SSE FXSR SSE2 TM PBE
bogomips：1179.64GNU C库的稳定版本2.3.2版本，由罗兰·麦格拉思等。
由GNU CC版本3.2.2 20030222（Red Hat Linux的3.2.2-5）编译。
编译一个Linux 2.4.20系统上2003-03-13。
可用扩展：
        GNU libio由每Bothner
        墓穴由迈克尔很高兴和其他附加2.1版本
        的linuxthreads-0.10由Xavier乐华
        BIND-8.2.3-T5B
        通过Alpha处理器公司赞助libthread_db所工作
        NIS（YP）/ NIS + NSS由和Thorsten Kukuk模块0.19ATOM：（正常工作在此设备上）
2.6.35＃25 SMP周一3月12日9时02分45秒PDT 2012 i686的的i686 i386的GNU / Linux的
==========
[根@ n00E04B36ECE5〜]＃执行cat / proc内/ cpuinfo
处理器：0
VENDOR_ID：GenuineIntel
CPU系列：6
型号：28
型号名称：正版英特尔（R）CPU N270 @ 1.60GHz的
步进：2
CPU兆赫：1599.874
缓存大小：512 KB
fdiv_bug：无
hlt_bug：无
f00f_bug：无
coma_bug：无
FPU：是
fpu_exception：是
CPUID等级：10
WP：是
标志：FPU VME德TSC MSR，PAE MCE CX8 APIC月MTRR PGE MCA CMOV拍拍CLFLUSH DTS ACPI MMX SSE FXSR SS SSE2 HT TM PBE NX constant_tsc了arch_perfmon PEBS BTS aperfmperf PNI dtes64监控ds_cpl EST TM2 SSSE3 xtpr PDCM movbe lahf_lm
bogomips：3199.74
CLFLUSH尺寸：64
cache_alignment：64
地址尺寸：32位物理，32位虚拟
能源管理：
GNU C库的稳定版本2.5版，由罗兰·麦格拉思等。
由GNU CC版本4.1.2 20080704（红帽4.1.2-44）编译。
编译一个Linux 2.6.9系统上2009-09-02。
可用扩展：
        的C存根附加2.1.2版本。
        墓穴由迈克尔很高兴和其他附加2.1版本
        GNU libidn这个由Simon Josefsson拥有
        GNU libio由每Bothner
        NIS（YP）/ NIS + NSS由和Thorsten Kukuk模块0.19
        本地POSIX线程库由乌尔里希Drepper等
        BIND-8.2.3-T5B
        RT使用linux内核AIO
线程本地存储的支持包括在内。


我能做些什么，以确定是什么原因造成这个问题？
如何试图静态针对某一版本的libc的链接？

GDB下发生故障后，我执行：

 （GDB）X / 1I $ EIP
0x40001cce：DIVL 0x164（％ECX）
 

 （GDB）信息章
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：00000000
（GDB）
 

根据我收到的帮助

看来，由于某种原因，libc中启动code由0分

现在的问题是，是什么原因造成这显然不好的行为？一定有什么别的东西不兼容？

大会输出：

  [JRN @本地〜] $更多fail.s
        .filefail.c
        。文本
.globl主
        .TYPE为主，@function
主要：
        莱亚尔4（％ESP），ECX％
        和L $ -16，ESP％
        pushl -4（ECX％）
        pushl％EBP
        MOVL％ESP，EBP％
        pushl％ECX
        MOVL $ 0，％EAX
        popl％ECX
        popl％EBP
        莱亚尔-4（ECX％），ESP％
        RET
        .size为主，。，主
        .identGCC（GNU）4.1.2 20080704（红帽4.1.2-52）
        .section伪.note.GNU堆栈，，@ PROGBITS
 

解决方案

这是要听起来像一个真正的长镜头...但你可以试试下面的？

  $ readelf -a失败
 

和寻找一个GNU_HASH动态标签？我的猜测是二进制使用 GNU_HASH 和您的 ld.so 太旧去了解它。对于GNU散列部分的支持添加到glibc的2006年左右，和干线发行版开始成为GNU的哈希只有大约2007年或2008年。你迅驰的的glibc 是 2003 的，其中predates GNU散列。

如果在 ld.so 不理解GNU散列，它会尝试使用老顽童哈希部分代替，里面是空的。特别是，我怀疑你的崩溃是在<一个发生href=\"http://repo.or.cz/w/glibc.git/blob/85c54a327d4c05381603eb49792afa5ad5dbe46c:/elf/do-lookup.h#l74\">this在行精灵/ DO-lookup.h ：

 为（symidx = MAP-GT＆; l_buckets [哈希％MAP-GT＆; l_nbuckets]。
 

由于链接器presumably不理解GNU哈希值， l_nbuckets 是0，导致崩溃。需要注意的是地图是一个大的结构有100结构元素，而 l_nbuckets 是围绕结构在第90成员新 ld.so （ 0x164 = 4 * 89 ，所以在旧的 ld.so 这大概precisely该成员）。

要看看这是的确凿的问题，建立与轮候册， - 哈希风格= SYSV 或轮候册， - 哈希风格=两者，看看是否崩溃消失

I am trying to build a simple C program for two different Linux environments. On one device the program runs fine, on the other device the program generates a floating point exception. The program does nothing but return 0 from main which leads me to believe there is some incompatibility with the start-up code perhaps ABI?

The program is compiled with gcc with the following build specs:

Using built-in specs. Target: i386-redhat-linux Configured 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 Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)

The program source is the following:

int main()
{
        return(0);
}

On the 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 think to gather to help find 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 is causing this problem? How about trying to statically link against a certain version of libc?

After failure occurs under GDB I execute:

(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 I've received it appears that for some reason the libc startup code is dividing by 0.

The question now is, what is causing this obviously bad behavior? Something must be incompatible with something else?

Assembly output:

[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

解决方案

This is going to sound like a really long shot...but can you try the following?

$ readelf -a fail

and look for a GNU_HASH dynamic tag? My guess is that the binary uses GNU_HASH, and your ld.so is too old to understand it. Support for the GNU hash section was added to glibc around 2006, and mainline distros began to be GNU-hash-only around 2007 or 2008. Your Centrino's glibc is from 2003, which predates GNU hashing.

If the ld.so doesn't understand GNU hash, it will try to use the old ELF hash section instead, which is empty. In particular, I suspect your crash is occurring at this line in elf/do-lookup.h:

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

Since the linker presumably doesn't understand GNU hashes, l_nbuckets would be 0, resulting in the crash. Note that map is a large structure with around 100 structure elements, and l_nbuckets is around the 90th member of the structure in newer ld.so (0x164 = 4*89, so in older ld.so it is probably precisely this member).

To see if this is conclusively the problem, build with -Wl,--hash-style=sysv or -Wl,--hash-style=both and see if the crash goes away.

这篇关于漂浮在'点异常（SIGFPE）INT的main（）{回报（0）; }“的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！