一直以來寫程式還算比較穩健, 每個模組的整合都先通過大量的單元測試, 很少出現嚴重的記憶體錯誤, 不過百密難得一疏, 前幾天在查詢一處疑似記憶體洩露問題的時候測出乙個段錯誤... 杯具... 查了大段大段的**也沒有發現異常(事實證明這是一種不僅低效而且存在思維定勢的審查方式)... 無奈之下讓我又想起了valgrind
果斷開啟valgrind, 新增引數 -v --tool=memcheck --leak-check=full --log-file=memcheck.log, ok, 很快完成了一次壓力測試, 因為有valgrind的保護導致程式正常執行完畢, ok, 檢視log很快就找到了一處記憶體定址錯誤, 檢視**, 發現這是一處低階的編碼錯誤, 給epoll申請epoll_event的malloc傳入長度有問題, 申請了並不足以容納所有事件資訊的長度... 杯具由此誕生... 修復之~ ...
回顧一下整個事件, 頭天晚上發現問題, 回去後經過了n次反覆測試, 找到了能正確復現bug的條件, 但是出錯的情況很詭異, 並沒有頭緒... 隔天接著測... 查閱大量**無果... 啟用valgrind, 5分鐘解決.... , ok, 不過值得注意的是, 這不意味著我會及其的依賴valgrind, 通過這次錯誤讓我建立起更強的**編寫意識, 更嚴格的測試邊界, 保證模組整合的安全度足夠高, 不過今後在系統測試的時候會增加valgrind測試的環節, 防範單元測試沒有發現的問題 :)
用valgrind檢測glib的記憶體錯誤
前段時間我們發現乙個daemon總是隨機的crash，對於這種隨機的crash的bug，我們自然會想到是記憶體越界問題引起的。但是用valgrind檢測卻沒有發現任何錯誤，那部分 比較複雜，結果花了幾天也沒有發現任何線索。後來，我想起glib裡有自己的記憶體管理機制，通過glib分配的記憶體是gli...
使用Valgrind查詢記憶體洩漏
在網上找了乙個c語言版本的base64 編譯通過，不過執行的時候報了corrupted size vs.prev size錯誤 網上查了一下資料，大致說是記憶體洩漏。但是怎麼分析哪兒洩漏，為什麼洩漏？在網上找到一款神器valgrind 專用於分析記憶體洩漏等各種疑難雜症。1 安裝 to instal...
Valgrind的記憶體洩露
有多種方法來定義 記憶體洩漏 特別地，在程式設計師中通常使用的 記憶體洩漏 的兩個主要定義。記憶體洩漏 的第乙個常用定義是 記憶體已分配，並且在程式終止之前不會被釋放。然而，許多程式設計師 正確地 認為，符合該定義的某些型別的記憶體洩漏實際上不會引起任何問題，因此不應該被認為是真正的 記憶體洩漏 記...