單步到崩潰地點(diǎn)，有數(shù)組取數(shù)據(jù)和拷貝操作，猜測(cè)數(shù)組越界導(dǎo)致的棧溢出。就開始找越界檢查工具。
vs自身帶的/GS只是在棧溢出時(shí)蹦個(gè)異常，不會(huì)給你定位崩在哪。所以找了會(huì)兒別的工具，boundschecker還沒找到下的地方，IBM的purify跨平臺(tái)但是收費(fèi)，另外免費(fèi)好用的就是linux下的valgrind了。這幾種內(nèi)存檢查工具都可以檢查內(nèi)存泄露和越界之類的。只是項(xiàng)目現(xiàn)在趕進(jìn)度，linux平臺(tái)的編譯還沒時(shí)間解決，內(nèi)存統(tǒng)一檢查就作罷。
開始看看能不能查dump。dump不是原生的dmp而是歷史代碼里重存為別的了。vc調(diào)試不很熟練，就索性把重存dump那塊兒的catch給干掉了。直接讓編譯器崩到代碼塊兒再看看能不能看出什么問題。
崩停到具體代碼行了，很驚喜，趕緊看看各變量?jī)?nèi)存狀況，問題數(shù)組是一個(gè)指針數(shù)組，這次驚喜的發(fā)現(xiàn)之前單步的那個(gè)下標(biāo)對(duì)應(yīng)在數(shù)組元素指針跟別的不一樣，為0xcdcdcdcd，確認(rèn)了下為vc下為未初始化的指針。
這樣就好查了，問題定位到了，后邊的就不啰嗦了。
最終問題是，同事給一個(gè)類新加了幾個(gè)指針成員，但是這幾個(gè)沒有new出來初始化之。唉……只能感嘆下敏捷開發(fā)那本書里說的，架構(gòu)師要參加編碼，我覺得要加點(diǎn)兒，就是架構(gòu)師要參與編碼還要參與測(cè)試調(diào)試自己的代碼。