如何找出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停止的原因

回答

相關問題