轉自：http://shafeng.github.io/2017/05/10/asan/

?

最近線上的程序總是莫名其妙崩潰,因為我們的項目使用了分布負載的機制,對于玩家的影響其實很小,但是我肯定是忍不了的…程序崩潰的core文件里面完全找不到問題所在,初步分析應該是野指針導致,仔細分析程序之后并沒有發現內存釋放后沒有置null的情況,很可能是多線程導致的,然而代碼量太大,大海撈針實在是無法找到問題所在,所以我找到了asan,項目之前一直用gcc4.4編譯,完全不知道asan的存在,asan是gcc4.8以上gcc自帶的內存檢測庫,開發自google,在gcc4.8版本以上編譯鏈接的時候加入指定的參數即可,非常的方便好用,而且對程序的性能影響并不大,如果你的程序平時耗費的cpu和內存資源不超過50%,那么完全可以把加入asan的程序放到線上去跑.

首先在編譯機上升級gcc,我直接升級到了最新版本gcc6.3版本(寫這篇記錄的時候最新版已經到gcc7.1了),升級后系統庫中會新加入libasan,我們使用asan的功能都是來自于這里.
然后對代碼進行編譯和鏈接,編譯時使用 -g -O2 -fsanitize=address -fno-omit-frame-pointer .-fsanitize=address命令就是將asan編譯進來,這樣編譯的.o文件在運行時stack上申請的內存都會被asan接管,如果出問題asan會第一時間輸出報告,如內存越界和各種非法訪問. -fno-omit-frame-pointer可以防止一些優化導致指針喪失可讀性. 鏈接時使用-fsanitize=address -fno-omit-frame-pointer選項可以讓程序在heap上申請的內存被asan接管,這樣asan會監控new和delete來輸出內存泄漏的報告.

大功告成,使用asan編譯和鏈接的程序生成好之后放到了線上環境運營,很快出現了一次宕機,asan會直接把自己的輸出當做error輸出,你可以查看到當前導致宕機的內存位置和變量名,文件行數,變量來源,線程信息等等非常全面的信息,得到這些信息后很快就分析出原來崩潰來自一個多線程共享的模塊,而當前模塊在多線程競爭資源的地方沒有加鎖,導致同一塊內存被寫壞. 問題完美解決,程序再也不會宕機了.

總結一下,asan在檢測程序內存方面的功能實在是強大,之前也用過valgrind來檢查內存泄漏,但是valgrind對性能的影響實在是太大,完全不能放到線上環境這樣真實的環境下測試,而且asan給出的問題報告相當詳細,基本上看一次錯誤報告就能解決當前導致宕機的問題,而core文件的信息由于優化和其他程序上下文的差異會導致提供的信息基本上沒什么作用.宕機十次,十個core文件也無法準確定位某些野指針錯誤的問題.對于asan,只有一個詞能表達我的心情,那就是相見恨晚…asan你值得擁有,誰用誰知道.

總結

以上是生活随笔為你收集整理的ASan(Linux)，gcc4.8以上版本自带的内存检查工具的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。