最近在修改乙個記憶體的問題，表面上看是乙個野指標的 bug .該 bug 只在裝置上出現，win32上無法重現。xcode 的 instrument 根本沒法定位問題，win32 上使用了 dr memory ，也沒找到根源。最後終於發現了問題， 其實原因說起來也很簡單，就是在操作記憶體時發生了越界。我們專案在讀取檔案時候，採用讀取自己壓縮好的資料報的方式，每次讀 size 個 char,放到 char[ ] 陣列裡。 但是卻給 char[size]這個位置設定了乙個結束符，而該陣列操作[ size ] 時發生了越界，導致遊戲非常不穩定，出現許許多多莫名其妙的野指標 crash .
這麼一說來，原理很簡單，錯誤也很低階，但是從排查到解決用了將近 7 個工作日，並且期間還有另外乙個同事也在一起看這個問題。
如果這塊**在 windows上也執行， dr memory 應該是能夠檢測出來的， 但是因為這塊**在 ios 的巨集裡面，所以 dr memory 沒有查出問題。
xcode 的 instrument 雖然沒有用，但是 xcode 可以像下圖這樣編輯 scheme ，來方便的定位問題。
編輯 scheme 的方法是點 xcode 上方的 product ---> scheme ---> edit scheme
上面是從網上別的地方找到的圖， xcode 版本額比較老，但是大同小異， 新版本的 xcode 也基本包含這幾項。
我們的 crash bug ，在做了上面的設定之前， 本來非常難以重現， 並且即使重現後，crash 的地方，也指向的是問題表現出來的現象，而不是問題發生的位置。
這樣設定之後， crash 的地方基本定位在問題發生的地方，即越界操作了 char[ size ] 這快記憶體時， 程式就 crash 了。由此可見這樣設定之後， xcode debugger 能夠幫助排查這樣的非法記憶體操作行為。
在像上圖這樣設定後， 因為乙個奇怪的原因，在真機上無法除錯，但是在 mac的 ios 模擬器上可以除錯。我們定位問題，就是在模擬器除錯過程中定位到的。
解決了這個問題後，我們的遊戲變得非常穩定，乙個星期的努力沒有白費 ，大家都很開心。
通過解決這個 bug ，我總結了一下幾點:
1. 只要是有重現規律的 bug ,哪怕再複雜，也算是比較容易解決的 bug
2. 了解了 dr memory 的使用，有助於排查 win32 上的記憶體問題
3. 了解了 xcode scheme 像上圖這樣設定，能夠在 xcode 上排查記憶體問題
5. 多讀書，多寫底層**，才能從一開始就避免這樣的情況發生。
解決了乙個小問題
原來在debian上使用mplayer w32codecs一直彈出 error could not open required directshow codec drvc.so 的惱人的小問題，今天google了一下，參照fc6下mplayer安裝 執行 發現也有乙個類似libstdc so.5 n...
今天解決了乙個空指標
swagger裡傳入請求資料時，老是報nullpointerexception debug時發現會出現這麼一行 cannot find local variable 原因是資料庫表裡後來加了個擴充套件欄位param1，然而在請求報文裡有命名規範為sid，雖然實體類裡改了資料庫的字段，但是請求報文轉換...
乙個巨集解決 iOS螢幕適配
用乙個巨集 解決 ios各種機型的螢幕適配問題 前提條件 設計師給出的效果圖應以iphone6p為基準。什麼時候使用這個巨集？所有控制項的尺寸 x值y值，cell的高度，文字的字型大小 如何使用這個巨集？在 supporting files 資料夾中的 prefixheader.pch 編寫 def...