为什么 gdb 会在断点处自动继续？答案

【问题标题】：Why might gdb automatically continue on a breakpoint?为什么 gdb 会在断点处自动继续？
【发布时间】：2016-11-25 21:21:06
【问题描述】：

我正在开发一个在 Android 上调试的 C++ 应用程序；碰巧的是，在某些设备上，此应用程序崩溃了。我已经将它缩小到一个函数，我尝试在ndk-gdb 中使用断点进行调试。第一次，在启动时，该函数运行并且中断正常，例如：

Breakpoint 1, MyApp::MyFunc (this=0xb8541c40, curel=0xb8cb7e68, doShow=false)
    at /path/to/src/MyApp.cpp:1600
1600      myObj.clear();
(gdb) c
Continuing.

这里，显然我自己输入了c 和ENTER；但随后，在用户操作时，该函数第二次运行，我得到了这个：

Breakpoint 1, MyApp::MyFunc (this=0xb8541c40, curel=0xb8cb7e68, doShow=true)
    at /path/to/src/MyApp.cpp:1600
1600      myObj.clear();
(gdb) 
Continuing.

Program received signal SIGABRT, Aborted.
0xb6f7b1b0 in tgkill ()
   from /path/to/obj/local/armeabi-v7a/libc.so
(gdb) 
Continuing.

Program received signal SIGABRT, Aborted.
0xb6f7b1b0 in tgkill ()
   from /path/to/obj/local/armeabi-v7a/libc.so
(gdb) 
Continuing.

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

所以，这里的断点确实命中了，但它没有中断——即使我没有按c，它也会继续“继续”，一次又一次地点击 SIGABRT “继续”，最后是程序终止。

从这里有限的信息中，有人知道为什么会发生这种情况，以及如何补救吗？例如，这可能是由于优化（应用程序在应该是调试模式下编译，但可能仍然存在一些优化）？顺便说一句，这是 GNU gdb (GDB) 7.7，android-ndk-r10e。

【问题讨论】：

在再次命中断点之前，代码第二次使用 SIGABRT 崩溃。当您获得 SIGABRT 时，请查看回溯。
感谢@SamVarshavchik - 偶尔它会在 sigabrt 处停止，我尝试发出回溯，但它没有显示任何明显的东西......但是很高兴能澄清断点没有第二次击中，我会再试一次 - 干杯！

标签： c++ debugging android-ndk gdb

【解决方案1】：

该死，我是笨蛋:).. 看，我第一次发出c 后，我在gdb 中收到一堆消息，然后它们在应用程序等待时暂时停止输入。而且，通常我在这里按 ENTER 几次，所以我在终端输出中有几行空行，以在日志中划定一个新阶段。

但是，gdb 将 ENTER 解释为“重复上一个命令”，这里是 continue，因此，它基本上在断点和 sigabrts 发生时“运行”（我确实觉得很奇怪，为什么我只能在 sigabrt 获得休息时间有时）。

好吧，就是这样 - 在调试 :) 时不要按 ENTER 在终端输出中腾出空间（并确保之前与 @987654326 严重终止的会话没有挂起的进程@)

【讨论】：