2010-08-01 83 views
4

我的應用程序使用GLUTesselator來鑲嵌複雜的凹多邊形。它在我運行普通版本的exe時會隨機崩潰,但如果我在VS中開始調試,它永遠不會崩潰。我發現這裏這個權利這基本上是我的問題:爲什麼某些事情永遠不會崩潰調試器?

The multi-thread debug CRT (/MTd) masks the problem, because, like 

Windows並通過 調試器產生的進程,它提供給你的 程序的調試堆,這是 初始化爲0XCD模式。 可能在某處使用 未初始化的內存區域作爲指針從 堆中取消引用 它;與這兩個調試堆你 離開它由於某種原因(也許 因爲地址0xbaadf00d和 0xcdcdcdcd還有的有效分配 內存),但與「正常」堆 (也就是常初始化爲0)你 得到一個訪問衝突,因爲你取消引用一個空指針 。

問題是在GLU32.dll發生崩潰,我無法找出爲什麼它有時試圖解引用空指針。當我的多邊形變得相當大並且有很多點時,它似乎會這樣做。我能做什麼?

謝謝

+0

調試器速度較慢,因此在多線程環境中,可能得不到相同的結果。 – 2010-08-02 00:32:49

+2

步驟1:儘可能提高警告等級。第2步:將所有警告視爲錯誤。第3步使代碼編譯。在修復所有遇到的問題時,只需將警告級別提高即可發現代碼中的錯誤。 – 2010-08-02 03:17:30

回答

3

這是一個生活中的事實,有時程序在調試器中的行爲有所不同。在你的情況下,一些內存的初始化方式不同,它的佈局也可能不同。併發程序中的另一個常見情況是時序不同,並且調試器中競爭條件通常不經常發生。

您可以嘗試手動將堆初始化爲不同的值(或者查看Visual Studio中是否有此選項)。通常初始化爲非零捕獲更多的錯誤,但在你的情況下可能不是這種情況。您也可以嘗試使用您的程序的內存映射來安排頁面0xcdcdc000未映射。你可以試試這個(它可能會使程序的運行速度遠遠超過一個可變的斷點)。在這種情況下,Visual Studio可以設置一個訪問特定內存地址的斷點。

2

但它從不崩潰,如果我開始在VS中調試。

嗯,我不知道確切爲什麼但同時在Visual Studio程序調試有時可以訪問,將使其崩潰沒有調試某些內存區域脫身。但我不知道確切的原因,但有時0xcdcdcdcd和0xbaadfood與此無關。它只是訪問某些地址不會導致問題。發生這種情況時,您需要找到猜測問題的其他方法。

我該怎麼辦?

可能的解決方案:

  1. 在程序安裝異常處理程序(_set_se_translator,如果我沒有記錯)。訪問衝突請嘗試MinidumpWriteDump。稍後使用Visual Studio進行調試(afaik,崩潰轉儲調試在快速版本中不適用)或使用windbg。
  2. 使用即時調試器。非快速版的視覺工作室具有此功能。可能有其他選擇。
  3. 編寫自定義的內存管理器(即會覆蓋新/刪除,並會提供的malloc /免費的替代品(如果你使用它們)),將攫取大塊的內存,鎖定與VirtualProtect所有未使用的內存。在這種情況下,即使在調試模式下,所有無效訪問都會導致崩潰。這種內存管理器需要大量內存,因爲要被鎖定,每個塊應該與頁面對齊。
  4. 爲所有可疑的函數調用添加過多的日誌記錄。將大量文本/調試信息轉儲到文件(或stderr)中 - 參數值,數組,您懷疑可能與崩潰相關的所有內容,在每次寫入文件後刷新,否則在崩潰過程中會丟失一些信息。這樣你就可以猜測程序崩潰之前發生了什麼。
  5. 嘗試調試版本構建。如果在項目設置中爲發佈版本啓用「調試信息」,您應該可以在某種程度上做到這一點。
  6. 嘗試在項目屬性(configuration properties->c/c++->code genration)中打開/關閉「基本運行時檢查」和「緩衝區安全檢查」。
  7. 嘗試尋找某種外部工具 - 例如valgrind或bounds checker。儘管如此,就我的預測而言,#3比這種方法更可靠。雖然這真的取決於問題。
2

鏈接到一個較早的問題,兩種思想。

首先,你可能想看看以前question有關Valgrind的替代窗戶。很多關於程序的提示都會幫助你。

現在的想法:

1)調試器可以從正在測試的代碼崩潰停止你的程序,但它不解決問題。最糟糕的情況是,你只能在街上踢球,但仍然存在腐敗現象,但從運行方式上看並不明顯。當您發貨時,您可以放心,有人會再次遇到問題。

2)經常發生在這樣的情況下,什麼是錯誤不是發生問題近。雖然您可能會注意到GLU32.dll中的問題,但可能是之前可能發生了損壞,甚至可能是在不同的線程或函數中,這並不會導致問題,並且在稍後的某個時間點程序會返回到損壞的區域並失敗。

+0

+1,很好的答案。 Valgrind對於這類問題非常棒。我從來沒有使用Windows的替代品之一,但如果它們中的任何一個都像valgrind一樣好,他們會很快發現他的問題。 – 2010-08-02 06:15:45

相關問題