如何找出gdb停止的原因

使用GDB调试程序时，我一直在调试模式下停止程序时遇到问题。当我进行回溯时，我发现它深藏在专有的第三方库调用堆栈中，我正在寻找为什么程序已停止。我仍然只是GDB初学者，所以我仍然不确定如何做到这一点。回顾一下，我发现“__cxa_throw（）来自/usr/lib64/libstdc++.so.6”，所以我假设抛出了某种异常，但我想知道如何获得更多关于它的信息，如果可能。如何找出gdb停止的原因

来源

2014-02-17 Brian

gdb“向上”命令可让您将焦点移到调用堆栈的更高一级。如果您在代码存在的例外之前移动到某个点，您可以看到当时正在执行的操作（并希望确定您是否调用了具有错误数据的函数）。 – mah

我这样做，我的代码中的一切似乎都很好（至少根据他们的文档）。 – Brian

如何找出为什么GDB已经停止

GDB通常会告诉你马上，例如

Program received signal SIGABRT, Aborted. 
0x00007ffff7750425 in __GI_raise (sig=<optimized out>)

程序因为接收到信号而停止。

我发现它在专有的第三方库调用堆栈中很深，我正在寻找为什么程序停止了。

它已停止正好由于GDB告诉你的原因。

看着回溯，我注意到__cxa_throw() from /usr/lib64/libstdc++.so.6所以我假设抛出了某种异常，但我想知道如何获得更多关于它的信息。

的__cxa_throw存在确实表明，异常被抛出（和std::terminate()存在表明它是未捕获的异常）。

而无需为第三方库的调试信息，你找到了事业的选择是有限的：

你可以阅读这方面的文档库，并仔细检查你有没有违反任何先决条件，它要求
您可以反汇编调用__cxa_throw的例程，并确定该例程被调用的原因。

来源

2014-02-17 15:56:45

尝试使用backtrace命令，该命令将显示您的程序如何处于它的状态。 Here你可以找到更多的细节。

来源

2014-02-17 14:27:30 tmaric

我试过了，它导致我发生异常，但不是为什么。如果对“为什么”的回答不可用，但这里是为了希望，我不会感到惊讶。 – Brian

hm。我通常会跳到一个框架，因为我有一个想法可能会导致问题。你可以用'list'命令在特定的框架中看到源代码吗？你确定你正在调试的代码是用'-ggdb -DFULLDEBUG -O0'选项编译的吗？ – tmaric

其实我可以自信地说我没有用任何调试信息构建的第三方库。*叹息* – Brian

如何找出gdb停止的原因

回答

相关问题