在網上找了乙個c語言版本的base64**，編譯通過，不過執行的時候報了corrupted size vs. prev_size錯誤
網上查了一下資料，大致說是記憶體洩漏。但是怎麼分析哪兒洩漏，為什麼洩漏？ 在網上找到一款神器valgrind 。專用於分析記憶體洩漏等各種疑難雜症。
1、安裝
to install from a tar.bz2 distribution:
4. run ./configure, with some options if you wish. the only interesting
one is the usual --prefix=/where/you/want/it/installed.
5. run "make".
6. run "make install", possibly as root if the destination permissions
require that.
7. see if it works. try "valgrind ls -l". either this works, or it
bombs out with some complaint. in that case, please let us know
(see www.valgrind.org).
gcc test.c -g，加上-g 選項，會保留**的文字資訊，便於除錯。最明顯的區別就是-g後會有錯誤**的行數形式，直接編譯為可執行檔案沒有行數，不好確定問題所在。
3、valgrind除錯
valgrind ./a.out即可檢視程式狀況
從資訊中可以看到，該**總共有四處越界。可以在越界處列印下標值，可以看到具體的越界值來修改malloc空間大小。
參考**：
很好的入門教程
用valgrind查詢記憶體錯誤
一直以來寫程式還算比較穩健,每個模組的整合都先通過大量的單元測試,很少出現嚴重的記憶體錯誤,不過百密難得一疏,前幾天在查詢一處疑似記憶體洩露問題的時候測出乙個段錯誤.杯具.查了大段大段的 也沒有發現異常 事實證明這是一種不僅低效而且存在思維定勢的審查方式 無奈之下讓我又想起了valgrind 果斷開...
使用 CrtSetDbgFlag檢測記憶體洩露
一 介紹 動態分配 記憶體是c c 程式語言乙個最強的特點，但是中國哲學家孫 sun tzu，我不知道是誰？那位知道？指出，最強的同時也是最弱的。這句話對c c 應用來說非常正確，在記憶體處理出錯的地方通常就是bugs產生的地方。乙個最敏感和難檢測的bug就是記憶體洩漏 沒有把前邊分配的記憶體成功釋...
使用memwatch跟蹤linux記憶體洩漏
參考 根據log可以查詢出申請了卻沒有釋放記憶體的行號。一 簡介 memwatch可以跟蹤程式中的記憶體洩漏和錯誤，能檢測雙重釋放 double free 錯誤釋放 erroneousfree 沒有釋放的記憶體 unfreed memory 溢位 overflow 下溢 underflow 等。解壓...