Linux C程序:SIGABRT来自何处? [英] Linux C program: where did this SIGABRT come from?

问题描述

在Fedora 22虚拟机上，我的C程序因SIGABRT而崩溃.GDB指向glibc存根中用于轮询系统调用的指令.拆卸看起来像这样:

On a Fedora 22 virtual machine, my C program is crashing with SIGABRT. GDB points at an instruction in the glibc stub for the poll system call. The disassembly looks like this:

 0x7f5359c46662 <poll+34>                mov    %rax,(%rsp)
 0x7f5359c46666 <poll+38>                mov    $0x7,%eax
 0x7f5359c4666b <poll+43>                syscall
>0x7f5359c4666d <poll+45>                mov    (%rsp),%rdi
 0x7f5359c46671 <poll+49>                mov    %rax,%rdx
 0x7f5359c46674 <poll+52>                callq  0x7f5359c5fa30 <__libc_disable_asynccancel>

(存根的源代码在汇编代码中，需要进行复杂的宏处理，因此在此处不值得引用.)

(The stub's source code is in assembly code subject to complex macro processing so it isn't worth quoting here.)

我不知道SIGABRT来自哪里.

I don't know where the SIGABRT is coming from.

民意调查系统调用手册没有说它可以引发SIGABRT.

The poll system call manpage doesn't say it can raise a SIGABRT.

还有另一个线程，但是它正在等待读取系统调用，因此我看不到它如何向崩溃的线程发送信号.

There is another thread but it is waiting on a read system call so I don't see how it could send a signal to the crashing thread.

我不知道系统中的任何代理都可能杀死-s SIGABRT"此过程.

I'm unaware of any agent in the system that might "kill -s SIGABRT" this process.

使用-D_FORTIFY_SOURCE = 2编译代码，这可能会导致SIGABRT，但我希望它是同步的，以便gdb指向引发它的代码.

The code is compiled with -D_FORTIFY_SOURCE=2, and this could cause SIGABRT but I would expect it to be synchronous so that gdb would point at the code that raised it.

推荐答案

两个潜在来源:

• systemd在看门狗计时器到期时发送SIGABRT，例如: https://lists.libreswan.org/pipermail/swan-dev/2016-July/001577.html

内核在出现紧急情况时可以SIGABRT用户态，例如: https://github.com/systemd/systemd/issues/917

the kernel can SIGABRT userland when it has a panic, for instance: https://github.com/systemd/systemd/issues/917

这篇关于Linux C程序:SIGABRT来自何处?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！