断点陷阱是否总是意味着程序是从调试器运行的？答案

【问题标题】：Does break point trap always mean program was run from the debugger?断点陷阱是否总是意味着程序是从调试器运行的？
【发布时间】：2019-08-20 11:42:39
【问题描述】：

我正在分析一个核心文件，上面写着：

Program terminated with signal 5, Trace/breakpoint trap

从这一行我可以确定这是由于程序在 GDB 下遇到了断点吗？

有没有在调试器下不运行时可能出现上述错误的情况？

【问题讨论】：

我对 Unix 系统的了解接近 0，但是我可以在这里添加一些东西：断点只是 CPU 处理的指令。当您在某个地址设置断点时，调试器实际上会更改代码并插入一条int 3 指令。当 CPU 执行这条int 3 指令时会产生一个异常，如果在调试下运行它会处理这个异常，如果不是在调试下，进程将崩溃，因为该异常不会被处理。
推测程序可能已经执行了raise(SIGTRAP);。
何时何地抛出此错误消息？

标签： c++ gdb

【解决方案1】：

不，程序不需要在调试器下运行才能发生这种情况。

尝试运行一个程序，然后使用kill -n 5 myProgram（或等效的kill -s SIGTRAP）。它将向有问题的程序发送一个 SIGTRAP 信号，这很可能会导致它终止。如果它在这个过程中产生了一个核心转储，那么它就会有你显示的消息。

或者，如 cmets 中所述，程序本身可能会发出该信号。

【讨论】：

是的，它是由监控进程发送的。
此外，程序可能执行了一个陷阱指令（例如，在 i386 和 x86_64 上的 __asm__((int3))），这将导致操作系统引发 SIGTRAP。这通常用作“不可能发生”情况的调试帮助。