2011-10-10 51 views
0

我C編碼的一個程序,使用NX打開C庫。我必須將它編譯爲.dll文件,並將其作爲32位計算機上的32位.dll文件運行,效果非常好。然而,當我把相同的代碼在Visual Studio 64位計算機上,並指定其編譯爲64位,和我運行程序,它崩潰上釋放一些內存一條線。當我爲64位版本註釋掉該行時,它運行良好。 NX Open文檔指出這是我應該釋放的內存。64位版本的DLL免費在內存中崩潰; 32位不

我的問題是這樣的:是什麼原因造成的?爲什麼編碼完全相同的程序會在64位機器上的64位版本上免費使用內存,而在32位機器上則不會使用32位版本?這是我應該預料到的嗎?我做了一些我可以預防的錯誤嗎?或者它是一個更大問題的症狀?

版本信息:我使用Visual Studio 2005中,NX 5.0.6.3中,Windows XP SP3

+1

對於任何碰撞,你需要在崩潰(異常,如訪問衝突)的位置來檢查調用堆棧。除了代碼中的錯誤之外的原因,細節取決於例外細節。 –

+6

有各種各樣的這種可能的解釋,但最有可能的是,你投一個指向32位整數,從而截斷了。在我們可以更具體地幫助之前,您需要縮小它的範圍。 –

+0

謝謝...然後,我會在獲取它時添加更多信息。 – Rae

回答

2

這很可能是某種類型的內存破壞漏洞。您可以:

  • 解除分配相同的內存兩次

  • 與已經釋放的內存工作(從而破壞新的內存分配)

  • 分配的內存(從而破壞其他分配或內存外寫管理結構)

這個錯誤很可能存在於32位版本中,但h尚未被發現,因爲它從未損壞重要數據。

它可以是很難找到這樣的錯誤。因此,我建議使用諸如Purify,Valgrind或Insure ++之類的內存調試器來檢測有問題的內存訪問的位置。

+0

我從這個角度開始研究這個問題,發現NX庫有一個特殊的UF_free()函數,我應該使用這個函數來代替普通的free()。到目前爲止,它似乎可以解決問題,但我會繼續尋找,看看我是否失去了其他東西。 – Rae

+0

在這種情況下,我沒有使用UF_free(),這意味着有一些內存管理是特定於NX在該函數中進行的。就我所知,這是一個32位和64位的問題,即使它沒有出現在32位版本中。 – Rae