一談到內存泄露, 多數程序猿都聞之色變。 沒錯, 內存泄露非常easy引入。 但非常難定位。 以你我的手機為例(如果不常常關機)。 如果每天泄露一些內存, 那么開始的一個星期, 你會發現手機好好的。 當內存泄露積累到一定程度, 那就是各種卡死了。 系統異常, 最后死機。 不得不重新啟動。
假設搞開發。 遇到內存泄露問題, 那就呵呵了。 你可能先得花好幾天來復現問題(泄露積累), 然后須要花好幾天來定位問題和改動問題, 然后又要花好幾天來驗證問題, 並且。 非常有可能沒法一次改好, 上述流程又要循環了。
確實挺苦逼的。
我個人覺得, 在內存泄露問題上。 主動預防比被動定位要划算得多。 但不管你怎么預防, 總有掉鏈子的時候, 所以, 有時候不得不去被動定位內存泄露。
在本文中。 暫不談論手機內存泄露問題的定位, 只介紹一個實用的linux小命令:mtrace(memory trace), 它能夠用來協助定位內存泄露。 搞開發的, 應該或多或少地聽說過mtrace.
以下, 我們來看看程序:
#include <stdio.h> int main() { setenv("MALLOC_TRACE", "taoge.log", "1"); mtrace(); int *p = (int *)malloc(2 * sizeof(int)); return 0; }有的朋友要說了, 一眼就能看出內存泄露啊。 可是。 當程序大了之后, 怎能只依靠肉眼? 好, mtrace該出場了。
編譯:gcc -g -DDEBUG test.c (千萬要注意, -g不可漏掉。 否則, 盡管最后能定位到內存泄露, 但卻找不到在代碼的第幾行。因為我代碼中沒有Debug宏控制, 所以編譯時, -DDEBUG是能夠省略的。 因此, 直接寫成gcc -g test.c就可以)
執行:./a.out
定位:mtrace a.out taoge.log
結果:
能夠看到, 有內存泄露,且正確定位到了代碼的行數。
我們想一下mtrace函數/命令的原理, 事實上也非常easy, 無非就是記錄每一對malloc/free的調用情況, 從這個意義上來講, mtrace替代了部分我們的眼睛, 緊緊地盯着malloc/free, 所以能看到泄露還是不泄露啊。
說明一下。 我的linux上並沒有安裝mtrace命令, 所以無法調試, 在網友Jukay的幫助下, 我才接觸到shiyanlou這個優秀的在線工具, 地址是:https://www.shiyanlou.com/ , 大家不須要注冊。 直接用QQ登錄就可以。 上面的過程就是在shiyanlou中做的。 沒有linux環境的朋友們。 以后就能夠在這上面玩了, 不要再扯理由說沒有linux環境啦。 再次感謝Jukay介紹這么優秀的在線工具。
OK, 本文先寫到這里, 興許會繼續介紹一些與linux有關的基本調試工具和方法。