使用gdb運行時，致命錯誤消失

我有一個程序會產生一個帶有testcase的致命錯誤，我可以通過讀取致命的日誌和堆棧跟蹤來找到問題 - 事實證明有一個讀操作在空指針上。使用gdb運行時，致命錯誤消失

但是，當我嘗試將gdb附加到它並設置圍繞可疑代碼的斷點時，空指針就不能被觀察到！該程序運行平穩，沒有任何錯誤。

這是一個單進程的單線程程序，我之前沒有遇到過這種事情。任何人都可以給我一些意見嗎？謝謝。

附加說明：我還嘗試在致命觸發器代碼之前調用pause（）系統調用，並期望在致命點之前使程序休眠，然後在其上附加gdb，可悲的是，沒有發生致命錯誤。

來源

2011-07-05 solotim

用'valgrind' /'memcheck'嘗試調試？ –

ahh，海森堡的不確定性原理，適用於編程 –

臭名昭着的[heisenbug]（http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug） –

這只是猜測不看代碼，但調試器有時會這樣：

它們初始化某些東西你
操作的時序的變化

我不t在GDB上有報價，但是我確實有一個關於valgrind（授予兩個瘋狂不同的東西..）

My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening?

當一個程序Valgrind的下運行，其環境略有不同當它運行到本地。例如，的內存佈局是不同的，而線程調度的方式是不同。

同樣會去GDB。

大多數時候這並沒有任何區別，但能，特別是如果你的程序是馬車。

所以，真正的問題很可能在你的程序。

來源

2011-07-05 08:03:28 cnicutar

如果這是一個指針上的無效讀取，那麼不可預知的行爲是可能的。既然你已經知道是什麼導致了錯誤，你應該儘快擺脫它。一般來說，當處理錯誤的指針操作時，期望出現意外。

來源

2011-07-05 08:04:31 Sriram

可以有幾件事情發生了..申請的時間是可以改變的，所以如果它是一個多線程應用程序，這是可能的，你比如先設置就緒標誌，然後將數據複製到緩衝區中，沒有調試器附加的另一個線程可能會在緩衝區被填充或設置一些指針之前訪問緩衝區。

也有可能某些應用程序具有反調試功能。在調試器中運行時，可能從未觸摸過這段代碼。

分析它的一種方法是使用核心轉儲。您可以通過ulimit -c unlimited創建然後啓動應用程序並在核心轉儲，你可以將其加載到與gdb ./application ./core GDB你可以找到一個有用的寫在這裏：http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php

來源

2011-07-05 08:13:59 DipSwitch

謝謝，但正如我所說，應該有任何線程問題，因爲它是單線程的。不幸的是，我沒有權限運行ulimit：\ – solotim

噢，完全錯過了...更多的咖啡！打擾一下！ – DipSwitch

使用gdb運行時，致命錯誤消失

回答

相關問題