程式設計是碰到最麻煩的問題恐怕就是記憶體洩露了，記憶體洩露問題往往不易發現，特別是在記憶體洩露的大小很小的情況下，如果不是程式長時間執行，恐怕很難發現，而除錯記憶體洩露的問題也常常顯得相當困難，最傳統的辦法恐怕就是一行行地去檢查**了，而對於工程專案，往往涉及到很多人的工作，而且**量也是相當可觀的，要檢查記憶體洩露問題，靠一行行地讀**恐怕是相當頭疼的事情（雖然本人也做個這種傻事，囧...ps：後來發現是編寫rpc上層呼叫時，傳遞的引數是通過malloc產生的，而rpc呼叫的free函式並不會主動釋放在程式中malloc申請的空間，從而導致嚴重的記憶體洩露）。ok，看看有什麼工具可以幫助我們解決記憶體洩露的問題吧。
1.解壓bzip2 -d valgrind,x,x,x
2.進入安裝目錄配置./configure（不要加什麼--prefix引數指定安裝路徑，我指定了以後make出現異常，不指定就ok，當然，也可能是和機器有關，暫時忽略）
3.make&&make install
4.用valgrind -h看看這個工具的引數和用法
檢查記憶體洩露命令（利用memcheck工具）valgrind --tool=memcheck --leak-check=yes ./test就可以檢查test程式的記憶體洩露問題了。
t標註出的函式塊，這部分的**是指申請了記憶體空間後，指向該部分的記憶體空間的指標沒有free就直接指向其他記憶體空間或是直接被丟棄了，沒有free該指標申請的空間，這類申請最易出現記憶體洩露情況。
其實valgrind只能提供申請記憶體異常的函式，具體的分析還是由程式設計師自己分析，由於它沒有具體列印每個指標的申請和釋放情況，所以分析起來還是不夠方便（找了好久才定位到問題！），不知道是否有工具能夠將程式申請的指標malloc和free配對地列印出來，這樣更易於分析。
對於free空間異常的問題，常常令人頭疼，在gdb除錯環境下，你無法知道乙個指標指向的空間到底有多大，是否有其他的變數越界訪問了這個空間，如果直接使用free，可能出現段錯誤，而在gdb下列印你free的指標又是完全正確的，這個時候就可以用valgrind幫你檢視記憶體越界問題了，valgrind會在存在記憶體越界的block中列印invalid write of size提示你，你的**存在記憶體越界問題，然後，一切就簡單多了~~
Bash是個好工具
在嵌入式linux執行，發現 gunzip h gunzip invalid option h busybox v1.01 2005.09.15 19 25 0000 multi call binary usage gunzip option file uncompress file or stan...
Firebug和Yslow是個好工具
火狐瀏覽器上裝的firebug很久沒用了，昨晚開啟firebug和yslow，邊瀏覽部落格邊看 突然發現有幾個404，果斷開啟模板編輯。這使得網頁開啟速度提高了16毫秒，優化 如下 1 刪除了4個無用的css檔案，原因是上次整合css後忘記刪除了，導致開啟網頁時仍要載入這4個css檔案。感悟 有事沒...
Valgrind工具的使用
本文參考自 一 valgrind介紹 valgrind是執行在linux上一套基於 技術的程式除錯和分析工具，它的主要作者是獲得過google o reilly開源大獎的julian seward，它包含乙個核心 乙個軟體合成的cpu，和一系列的小工具，每個工具都可以完成一項任務 除錯，分析，或測試...