为什么gdb会在断点上自动继续？ 我正在研究一个C++应用程序，我在Android上调试它；碰巧，在某些设备上，此应用程序崩溃。我已经把它缩小到一个函数，我尝试在ndkgdb中用断点调试它。第一次，在启动时，该函数运行并正常中断，例如： Breakpoint 1, MyApp::MyFunc (this=0xb8541c40, curel=0xb8cb7e68, doShow=false) at /path/to/src/MyApp.cpp:1600 1600 myObj.clear(); (gdb) c Continuing.

在这里，我显然已经输入了

c

并输入了我自己；但是，在用户操作后，该函数将再次运行，我得到以下结果：

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。

该死，我真蠢

：）

。。看，在我第一次发布

c

之后，我在gdb中收到了一堆消息，然后它们在应用程序等待输入时暂时停止。通常我会按几次ENTER键，所以终端输出中有几行空行，用来在日志中划分一个新的阶段

但是，

gdb

将ENTER解释为“repeat last command”，这里是

c

continue，因此，当断点和sigabrt出现时，它基本上“运行”在断点和sigabrt上（我确实觉得奇怪，为什么我只是偶尔在sigabrt上得到中断）

---

好的，就是这样-在调试

：）时，不要按ENTER键在终端输出中留出空间。

（并确保先前与

gdb

严重终止的会话中没有挂起进程）

第二次代码崩溃时，在断点再次命中之前，使用SIGABRT。当你得到一个SIGABRT时，看看回溯。谢谢@SamVarshavchik-偶尔它会在SIGABRT处停止，我试着发出回溯，但没有显示任何明显的。。。但是很高兴澄清断点没有第二次命中，我会再试一次-干杯！