如何在 GDB 被杀死后从处理器中清除断点？

Question

当我的 SSH 连接断开时，我正在通过 SSH 调试在 Linux 环境中运行的 GDB 中的 Free Pascal 应用程序。我从经验中看到，发生这种情况时 GDB 已关闭，并且可以肯定的是，我运行了 pidof gdb 并没有返回任何内容。我重新打开 GDB 并附加到同一个正在运行的应用程序，我能够继续调试并在几分钟后完成。在我完成调试一个小时后，应用程序意外死亡。我唯一反映发生了什么的日志是：

Nov  5 16:29:59 kernel: [846469.866825] traps: Maintain[9065] trap int3 ip:7f5148924cf1 sp:7f51376a4420 error:0

经过一番研究，发送到应用程序的信号似乎会杀死它，除非它被调试器捕获。我的假设是这个信号是由程序到达我设置的断点引起的，而 GDB 不再可以捕获这个信号。

这是我的问题：

1. GDB 意外关闭后是否可以将断点陷阱留在处理器中？
2. 如果是这种情况，有没有办法在断点被应用然后意外关闭后从处理器中清除？

Answer 1

我的假设是这个信号是由程序到达我设置的断点引起的

这个假设很可能是不正确的：当 GDB 自动从进程中分离时，它会删除所有断点。

看起来陷阱地址7f5148924cf1属于某个共享库。

如果您有核心转储，或者在进程处于活动状态时记录了共享库的位置，您可以检查在该地址加载的库，并查看那里有什么指令。机会是：它是一个与任何 GDB 断点无关的 int3。将__asm__("INT3") 或__asm__(UD2) 放入“不可能发生”的分支并不少见，有效地实现了无法编译出来的assert。

另一种可能性：您的应用跳过了一个野函数指针。

我刚刚查看了objdump -d 的libpthread.so.0，我看到了很多INT3s：

__pthread_initialize_minimal:
...
    9479:       b8 00 40 00 00          mov    $0x4000,%eax
    947e:       e9 8f fe ff ff          jmpq   9312 <__pthread_initialize_minimal+0x1f2>
    9483:       cc                      int3   
    9484:       cc                      int3   
    9485:       cc                      int3   
    9486:       cc                      int3   
    9487:       cc                      int3   
    9488:       cc                      int3   
    9489:       cc                      int3   

sigcancel_handler:
...
    950c:       e8 2f 9e 00 00          callq  13340 <__pthread_unwind>
    9511:       cc                      int3   
    9512:       cc                      int3   
    9513:       cc                      int3   
    9514:       cc                      int3   

等等。如果应用程序曾经登陆，例如0x9511 或任何其他 INT3s，它将与 SIGTRAP 一起消失，就像您的应用一样。