带有SIGFPE异常的程序在gdb下的行为有所不同

Question

我有一个简单的C程序，在使用gdb调试时表现不同，而不是。 该计划是这样的：

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

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

当它自己运行时，我得到了这个非常奇怪的结果：

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

没错！ 这并不是说信号没有被触发，它是：

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

在GDB中，事情有所不同：

ezyang@javelin:~/Dev/ghc-build-sandbox/libraries/unix/tests/libposix$ gdb ./mini
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (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) r
Starting program: /srv/code/ghc-build-sandbox/libraries/unix/tests/libposix/mini 
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000

Program received signal SIGFPE, Arithmetic exception.
0x00007ffff7a49317 in kill () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) c
Continuing.

Program terminated with signal SIGFPE, Arithmetic exception.
The program no longer exists.

要求GDB不停止没有任何区别

(gdb) handle SIGFPE nostop
Signal        Stop  Print   Pass to program Description
SIGFPE        No    Yes Yes     Arithmetic exception
(gdb) r
Starting program: /srv/code/ghc-build-sandbox/libraries/unix/tests/libposix/mini 
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000

Program received signal SIGFPE, Arithmetic exception.

Program terminated with signal SIGFPE, Arithmetic exception.
The program no longer exists.

这是怎么回事？！ 首先，为什么SIGFPE没有杀死该计划; 第二件事，为什么GDB表现不同？

更新。 一种想法是子进程继承父进程的信号掩码。 但是，从本抄本中可以看出，情况显然不是这样： 这种分析不正确，见下文。

ezyang@javelin:~$ trap - SIGFPE
ezyang@javelin:~$ ./mini
I'm happy.

更新2.我的一位朋友指出陷阱仅报告由shell本身设置的信号，而不是任何父进程。 所以我们跟踪了所有父母的忽略掩码，并且看，rxvt-unicode已经屏蔽了SIGFPE。 一位朋友确认他可以在使用rxvt-unicode运行可执行文件时重现。

Answer 1

忽略的信号通过fork()和exec*()继承：

$ ./mini
Floating point exception (core dumped)
$ trap '' SIGFPE
$ ./mini
I'm happy.
$ trap - SIGFPE
$ ./mini
Floating point exception (core dumped)

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

事实证明，根本问题是他在urxvt中运行测试，它连接了libperl， 无条件地忽略了SIGFPE 。

Answer 2

SIG_IGN信号掩码和信号处置由子进程继承。 我能想到的唯一可能性是你的shell由于某些原因而屏蔽或忽略了SIGFPE ，并且在启动程序之前没有清除此状态。