關於記憶體的一些bug （轉）

從記憶體管理方面來講，C#是個完美的天堂，你不用像在C++中那樣萬分小心的管理著你的記憶體；儘管如此，本人還是喜歡C++要多些，正如微軟稱C++為native程式碼 - C++對我來講，的確是要更native一些。

其實，很多時候，C++之於C#，就像手動擋之於自動擋。

閒話不扯，一般情況下，我們會碰到的記憶體問題有使用未初始化的指標，使用空指標，釋放已經釋放過的記憶體等等。最近工作中也遇到兩個記憶體相關的問題，覺得記下來還是有些價值的。

誰分配，誰釋放

一個第三方提供的類的物件，每次析構的時候都會crash。仔細檢查後發現，我們在此之前new了一塊記憶體並將指標設給了該物件的一個成員(object.p)。於是懷疑該類在解構函式中試圖delete該塊記憶體。 試了一下在析構之前先將Object.p置0, 問題果然不再存在，於是基本可以確定是這個原因了。

這裡其實有兩個問題，一是我們的程式碼沒有釋放自己分配的記憶體；二是第三方庫的程式碼，不應該delete不是自己分配的記憶體。誰分配，誰釋放是一個相當重要的原則，一個試圖釋放使用者new出來的記憶體的第三方庫，至少存在以下問題：

1. 一般情況下，使用著會釋放自己new出來的記憶體，那麼這裡就會出現二次釋放的問題。
2. 如果任何一方過載了operator new和operator delete，定義了自己的記憶體池，那麼基本就是雞同鴨講了。
3. 如果傳給你的是一個棧上的物件呢，你也delete?
   
   

無意中被破壞的記憶體 

我們有一個基於記憶體的transaction manager，基本原理就是，每做一個資料修改就會將被修改過的記憶體備份起來，然後undo的時候，將備份的資料再覆蓋回來。當然，這裡需要被備份的記憶體，使用一種特殊的方式分配的，我們稱之為transacted memory。考慮如下流程：

1. 做一個資料修改，比如畫一個圓
2. 該操作需要將提供畫圓函式的DLL動態載入進來
3. 在該DLL載入及初始話化過程中，建立了一個transacted memory,比如說一個std::map
4. 畫圓完成後，做一個Undo操作 

於是該新畫出來的圓又被原記憶體覆蓋回去了，而同時，在載入DLL過程中分配的那個std::map也被覆蓋回去了，注意，載入DLL的過程並不會被undo，於是，當程式再次試圖訪問該map時出錯，因為該map的內容已經完全面目全非了。

這個bug花了我4、5個小時才發現問題所在，解決方法其實也很簡單，那就是避免在初始化DLL時分配transacted memory。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-672527/，如需轉載，請註明出處，否則將追究法律責任。