Question

我正在开发一个C ++应用程序，我在Android上调试;碰巧，在某些设备上，这个应用程序崩溃了。我把它缩小到一个函数，我尝试使用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。

Answer 1

该死的，我是愚蠢的:) ..看，发生的事情是我第一次发出c后，我在gdb中收到一堆邮件，然后他们暂时停止了该应用程序等待输入。并且，通常我按这里 ENTER 几次，所以我在终端输出中有一些空行，以分隔日志中的新阶段。

但是，gdb将 ENTER 解释为“重复最后一个命令”，这里是c ontinue，因此，它基本上“遍历”断点和sigabrts时它们发生了（我确实觉得奇怪为什么我只能在sigabrt得到休息有时候）。

嗯，就是这样 - 在调试:)时不要按 ENTER 在终端输出中腾出空间（并确保没有任何挂起进程来自以前严重终止的会话gdb）

为什么gdb会自动在断点上继续？

1 个答案: