Glib 程式記憶體洩漏檢測實戰：Valgrind 參數優化與結果分析全指南

編輯：關於C語言

為什麼需要特殊參數？

Glib 內部使用記憶體切片分配器（GSlice）與緩存機制，標準 Valgrind 檢測會誤報大量「possibly lost」內存塊。必須禁用 Glib 優化分配器，強制使用系統 malloc/free，才能獲得準確洩漏報告。

標準檢測命令模板

G_SLICE=always-malloc G_DEBUG=gc-friendly \
valgrind --tool=memcheck \
         --leak-check=full \
         --leak-resolution=high \
         --num-callers=20 \
         --show-reachable=yes \
         --log-file=valgrind.log \
         ./your_app

關鍵環境變量

G_SLICE=always-malloc：禁用 GSlice 切片分配器，所有分配直接走 malloc，讓 Valgrind 精確追蹤。
G_DEBUG=gc-friendly：讓 Glib 在程式結束時主動釋放所有內部緩存、全局變量，減少「still reachable」干擾。

核心 Valgrind 參數

--leak-check=full：輸出詳細洩漏堆疊追蹤（含源碼行號）。
--leak-resolution=high：高解析度匹配洩漏堆疊，區分相似調用路徑。
--num-callers=20：堆疊追蹤深度 20 層，覆蓋深層調用鏈。
--show-reachable=yes：顯示「still reachable」內存（全局/靜態指針指向），輔助判斷是否為刻意保留。
--log-file=：將龐大輸出導向文件，便於事後分析。

自動化腳本範例

#!/bin/bash
# valgrind_test.sh
killall ../bin/test 2>/dev/null
export G_SLICE=always-malloc
export G_DEBUG=gc-friendly
valgrind --tool=memcheck \
         --leak-check=full \
         --leak-resolution=high \
         --num-callers=20 \
         --show-reachable=yes \
         --log-file=valgrind_test.log \
         ../bin/test --verbose --no-daemon --timed-exit

實戰日誌深度解讀（節選分析）

LEAK SUMMARY 關鍵指標

==31312== LEAK SUMMARY:
==31312== definitely lost: 0 bytes in 0 blocks
==31312== indirectly lost: 0 bytes in 0 blocks
==31312== possibly lost: 689,572,150 bytes in 576,549 blocks
==31312== still reachable: 10,452 bytes in 9 blocks
==31312== suppressed: 0 bytes in 0 blocks

definitely lost = 0：無確定洩漏（無指針指向的內存塊），好消息。
possibly lost = 689 MB：大量「可能洩漏」，典型 Glib 內部結構（g_hash_table、g_slist、g_string、g_array）未釋放。需結合堆疊定位業務代碼創建這些對象的位置。
still reachable = 10 KB：極少量可達內存，通常為主程式刻意保留的全局資源，可忽略。

堆疊追蹤定位洩漏源頭

典型洩漏堆疊模式：

==31312== 4,856,400 bytes in 20,235 blocks are possibly lost in loss record 35 of 53
==31312==    at 0x4C26458: memalign (vg_replace_malloc.c:727)
==31312==    by 0x31A2055F47: ??? (in /lib64/libglib-2.0.so.0.2200.5)
==31312==    by 0x31A2056801: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5)
==31312==    by 0x31A2057D7D: g_slist_prepend (in /lib64/libglib-2.0.so.0.2200.5)
==31312==    by 0x40438A: mr_new (gsmmr.c:274)        <-- 業務代碼入口
==31312==    by 0x4048DC: read_gsmmr_file (gsmmr.c:414)
==31312==    by 0x40507B: read_mr_file (mrread.c:56)
==31312==    by 0x404BEE: test_read_gsmmr_file (test_mrread.h:26)
==31312==    by 0x404EE3: main (main.c:28)

關注 業務代碼層（綠色標記）：mr_new → read_gsmmr_file → main。
g_slist_prepend / g_hash_table_new_full / g_string_sized_new 等 Glib 容器操作未對應釋放（g_slist_free、g_hash_table_destroy、g_string_free）。
批量處理大量記錄（如 36 萬 MR 數據）時，若循環內創建容器而循環外未統一釋放，會導致記憶體線性增長。

修復策略清單

容器生命周期管理：g_hash_table_new_full 指定 key_destroy/value_destroy 回調，確保 g_hash_table_destroy 時遞歸釋放值內存。
循環內臨時對象：字符串、列表、數組用完即釋（g_free、g_list_free、g_array_free）。
GSList/GList 釋放陷阱：g_slist_free(list) 僅釋放節點，不釋放節點數據；需先遍歷 g_free(data) 或使用 g_slist_free_full(list, g_free)。
統一清理入口：主流程結束前調用自定義 cleanup_all() 釋放所有全局容器。

進階技巧

--track-origins=yes：追蹤未初始化值來源，定位 Conditional jump or move depends on uninitialised value(s) 錯誤根因。
VG_(VALGRIND_MALLOCLIKE_BLOCK) / VALGRIND_FREELIKE_BLOCK：在業務代碼嵌入 Valgrind 客戶端請求，標記自定義分配器內存塊，提升精度。
對比運行：G_SLICE=always-malloc vs 默認模式，差異即為 Glib 內部緩存佔用量。