2017-02-11 28 views
-1

我們可以列出一些原因,使得程序在調試模式下編譯時可以正確運行,但在Qt Creator中以發行模式崩潰。在大多數情況下,我們來談談一般情況。一般來說,在Qt Creator中,如果在調試模式下編譯但在發佈模式下崩潰,什麼會導致程序正常運行?

就我而言,在A點,程序編譯並正確運行。經過一些工作後,在B點編譯,但在運行時在發佈模式下崩潰,而不是在調試模式下,我通過在A和B之間評論我的工作返回到A點,它具有與B點相同的行爲,但編譯卻崩潰只在發佈模式下。我覺得在A點睡覺之前我做了很多錯誤。這使我不想完成我的程序,因爲它是我想要在開放源代碼中共享的免費程序。

+7

未定義的行爲是一個可能的原因。請注意所有編譯器警告。如果您沒有收到任何警告,則會增加編譯器的警告級別,並在增加後查看是否有任何警告。 – drescherjm

+1

你有任何代碼示例?目前的答案可能是廣泛的(至少對我而言)。 –

回答

1

任何一種未定義的行爲都會導致此類問題。最可能的原因 - 寫入數組/矢量的邊界,或從那裏讀取。它可以是對已經被破壞的物體的破壞。或者只有在釋放模式下執行速度很快時纔會重現的多線程問題。它可能是未初始化的struct,也可能是未在構造函數中分配的POD類型的字段。

在調試模式下,內存分配的方式不同,在某些情況下,最終可能包含零(傳遞給您的程序時)而不是隨機垃圾。這通常僅在發佈模式下導致崩潰。

我強烈建議您設置「RelWithDebInfo」配置來調試此問題,例如,在Release中構建時,將-g選項傳遞給GCC。因此,當應用程序崩潰並找出原因時,您將能夠停止在調試器中。

否則,最好的辦法就是在代碼中執行類似「二進制搜索」的操作來查找崩潰的確切位置。喜歡,評論一半的代碼,看看它是否仍然崩潰等。

我知道這個解釋有點含糊,但希望它有幫助!

+2

_「我知道這個解釋有些含糊......」嗯,對於一個太模糊而寬泛的問題,可以預料什麼? –

+0

「在調試模式下,內存分配方式不同,在某些情況下,最終可能包含零(傳遞到程序時),而不是隨機垃圾。」實際上,情況正好相反;調試堆使用固定模式填充重新分配的頁面以幫助發現未初始化的內存錯誤。 –

+0

@MatteoItalia我認爲你一般來說可能是正確的,我只是從我的經驗中講述。有沒有證據鏈接? :) –

相關問題