簡單的memory leak跟蹤 - 天堂裡的死神 -
c++編碼中memory leak是乙個很討厭卻又揮之不去的話題，最近由於引入了gc，為了驗證gc是否確實正常free了記憶體，於是先提供了乙個記憶體分配的tracer。
與分配器不同，分配器主要解決的是兩個問題：
1、效能，池式分配往往能提供比直接virtual allocation快得多的效能。據說這一原則在vista後無效了，因為微軟修改了va的實現機制，只是聽說，沒有實際測試過。
2、碎片，避免大量散記憶體分配沖散了本身連續的記憶體，導致後面記憶體因為沒有連續區塊而分配不出來。
我們的***tracer主要是想解決乙個問題，就是啥時候分了記憶體，啥時候刪的，程式退出時刪除掉沒。
基本上，這個主題之前也有很多前輩都寫過了，這裡也沒有超越前輩們的什麼方案，只是自己做這個模組時的心得和理解。
這個問題有兩個比較成型的方案，乙個就是mfc的debug_new方案，max sdk用的也是這個方案。
其實原理很簡單，我們只要能獲取到當前語句的檔名和行號，然後new的時候，我們讓我們的tracer記錄一下當前的位址，並與檔名和行號繫結，然後，delete的時候，按照位址來去掉這條記錄即可。
實現起來如何實現呢？
這個問題無非是要解決兩個問題，首先，new這個東西，我們需要接管下來，接管下來後才能記錄我們自己的資訊。
c++的operator new是可以有不同形式的過載的，比如：
?
void* operatornew(size_tinsize,constchar* inlogmsg)
Windbg找出memory leak的一種笨辦法
以下內容是 以前做專案碰到過乙個問題，在客戶的站點上面發現有嚴重的記憶體洩漏。幸運的是我們找到了重現的步驟，一輪下來大概有幾十兆的洩漏，但是以下常規方法卻沒啥用。專案有幾百萬行 但是我們認為可能發生大記憶體洩漏的就幾個點。把那幾個點的 都找了一遍，沒有任何結果。左尋右找，終於找到了一種比較笨但是卻很...
Bug跟蹤過程的簡單分析
這是乙個典型的bug跟蹤過程，設計者篤信只有完整的檢查才會保證修改乙個bug的時候不會產生另外乙個bug。但是現實好像總是跟他作對，bug返回率一直居高不下。於是設計者修訂了流程，增加了幾個步驟。他希望問題能夠通過複查被發現出來。但是增加了流程以後bug返回率反而提高了。這是人的問題！流程設計者認為...
Shell 指令碼學習 簡單的執行跟蹤
程式是人寫的，難免會出錯。想知道你的程式正在做什麼，有個好方法，就是把執行跟蹤的功能開啟。這會使得shell顯示每個被執行到的命令，並在前面加上 乙個加號後面跟著乙個空格。在指令碼裡，用 set x 命令將執行跟蹤的功能開啟，然後再用 set x 命令關閉它。這個功能對複雜的指令碼比較有用，不過這裡...