咳咳....
最近又在和C++的memory leak 打架
雖然有偵測工具的幫忙，但是仍然陷於一種完全慘敗的狀況 - 工具並沒有成功的告訴我 leak 在那裏。看著演算法明明對記憶體卻一路狂飆的感覺真是氣到爆表、慘到爆燈。
好吧，陷入愁雲慘霧沒有幫助，只好用最傳統的二元搜尋法看看到底是那裏作怪。
Mark掉一部份的code, 讓另一部份recursive 做下去，然後不斷縮小範圍，並且觀察每一段code與爆走記憶體間的causal relation。這個過程相當的慘烈.有誰知道更好的方法，請告訴我 Orz
最後終於找到一個物件 stringstream。
還有一篇文章
http://untidy.net/blog/2006/08/21/visual-c-2005-stringstream-leak/
這玩意看起來無辜到不行，簡直就像一般偵探小說裏的兇手一樣，一開始看起來絕不可能是犯人，卻兇狠的幹下了幾起兇殺案。碰到這種bug 只能自認倒楣，我大約花了六個小時在這詭異的東西上面。天呀.. 六個小時，可以把一部日劇看一半了。
我投降了，下回要改用managed C++
3 則留言:
加油啊!喵仔
雖然很想寫些安慰打氣的話，不過看起來6小時能搞定這樣的問題，好像已經很猛很順利了呀!
佩服多餘同情。
謝謝你們的打氣~~
其實這類的bug 只要寫程式的人多少都會遇到。只是…
時間就是金錢 朋友!
(還有從VC++ 6.0 用到2005，這類的bug 真的遇到蠻多，每次也都要花一段時間才能找到)
我只是很好奇是否有那種比較聰明的compiler，compile的時候還能去搜尋一下defect database，比對目前lib 的版次，再alert programmer 說，唉唉，這可能有錯喲~之類的 就算compile 要花十幾二十分鐘，也強過在那裏binary search 六小時啊
張貼留言