gpt4 book ai didi

c - 具有 SIGFPE 异常的程序在 gdb 下表现不同

转载 作者:太空宇宙 更新时间:2023-11-04 08:54:52 25 4
gpt4 key购买 nike

我有一个简单的 C 程序,它在使用 gdb 调试时表现不同。程序是这样的:

#include <stdio.h>
#include <signal.h>

int main() {
kill(getpid(), SIGFPE);
printf("I'm happy.\n");
return 0;
}

单独运行时,我得到了这个非常奇怪的结果:

ezyang@javelin:~$ ./miniI'm happy.ezyang@javelin:~$ echo $?0

没有错误!这并不是说信号没有被触发,它是:

ezyang@javelin:~$ strace -e signal ./minikill(31950, SIGFPE)                     = 0--- SIGFPE (Floating point exception) @ 0 (0) ---I'm happy

在 GDB 中,事情的处理方式不同:

ezyang@javelin:~/Dev/ghc-build-sandbox/libraries/unix/tests/libposix$ gdb ./miniGNU gdb (GDB) 7.5.91.20130417-cvs-ubuntuCopyright (C) 2013 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later 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:...Reading symbols from /srv/code/ghc-build-sandbox/libraries/unix/tests/libposix/mini...(no debugging symbols found)...done.(gdb) rStarting program: /srv/code/ghc-build-sandbox/libraries/unix/tests/libposix/mini warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000Program received signal SIGFPE, Arithmetic exception.0x00007ffff7a49317 in kill () at ../sysdeps/unix/syscall-template.S:8181  ../sysdeps/unix/syscall-template.S: No such file or directory.(gdb) cContinuing.Program terminated with signal SIGFPE, Arithmetic exception.The program no longer exists.

要求GDB不要停止没有区别

(gdb) handle SIGFPE nostopSignal        Stop  Print   Pass to program DescriptionSIGFPE        No    Yes Yes     Arithmetic exception(gdb) rStarting program: /srv/code/ghc-build-sandbox/libraries/unix/tests/libposix/mini warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000Program received signal SIGFPE, Arithmetic exception.Program terminated with signal SIGFPE, Arithmetic exception.The program no longer exists.

这是怎么回事?!一方面,为什么 SIGFPE 没有终止程序?第二,为什么 GDB 的行为不同?

更新。一种想法是子进程正在继承父进程的信号掩码。 但是,正如在这段文字记录中所见,情况显然并非如此: 此分析不正确,请参见下文。

ezyang@javelin:~$ trap - SIGFPEezyang@javelin:~$ ./miniI'm happy.

更新 2. 我的一个 friend 指出,trap 只报告由 shell 本身设置的信号,而不是由任何父进程设置的。所以我们追踪了所有 parent 的忽略掩码,你瞧,rxvt-unicode 屏蔽了 SIGFPE。一位 friend 在使用 rxvt-unicode 运行可执行文件时确认他可以重现。

最佳答案

忽略的信号在 fork()exec*() 之间继承:

$ ./miniFloating point exception (core dumped)$ trap '' SIGFPE$ ./miniI'm happy.$ trap - SIGFPE$ ./miniFloating point exception (core dumped)

我与问题作者私下讨论了这个问题。由于 bash 从其父进程保存和恢复信号掩码,并且 trap 内置函数仅报告在当前 shell 中处理或忽略的信号,调试变得很复杂,即使从父进程继承的忽略信号仍然有效。

事实证明,根本问题是他在 urxvt 中运行测试,它链接 libperl,unconditionally ignores SIGFPE .

关于c - 具有 SIGFPE 异常的程序在 gdb 下表现不同,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17766149/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com