求助：glib 2.40.2 疑似內存泄漏問題

eglic_cu

初次使用Glib，代碼基本寫完之后，順手測試下，發(fā)現(xiàn)
GHashTable內存泄漏問題，不知是否使用方式不對？
另：g_key_file_new .. g_key_file_load_from_file ... g_key_file_free 同樣問題。。

精簡后最小測試代碼如下：

#include <glib.h>
int main(int argc,char **argv){
        printf("glib version = %d.%d.%d\n",glib_major_version,glib_minor_version,glib_micro_version);
        GHashTable *h = g_hash_table_new(NULL,NULL);
        g_hash_table_destroy(h);
}

編譯后運行之
valgrind --db-attach=yes --tool=memcheck --leak-check=full --show-leak-kinds=all ./test.bin

glib version = 2.40.2
==27702== HEAP SUMMARY:
==27702==     in use at exit: 2,076 bytes in 3 blocks
==27702==   total heap usage: 6 allocs, 3 frees, 2,260 bytes allocated
==27702==
==27702== 4 bytes in 1 blocks are still reachable in loss record 1 of 3
==27702==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27702==    by 0x56B08CD: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x56B0D28: g_private_get (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x568A20C: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x565E17D: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x4019E0: do_test_ini (test.c:122)
==27702==    by 0x40157A: main (test.c:24)
==27702==
==27702== 40 bytes in 1 blocks are still reachable in loss record 2 of 3
==27702==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27702==    by 0x56B058F: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x56B0634: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x56B0978: g_mutex_lock (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x5640D71: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x568A374: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x565E17D: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x4019E0: do_test_ini (test.c:122)
==27702==    by 0x40157A: main (test.c:24)
==27702==
==27702== 2,032 bytes in 1 blocks are still reachable in loss record 3 of 3
==27702==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27702==    by 0x5674668: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x5641015: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x568A374: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x565E17D: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==27702==    by 0x4019E0: do_test_ini (test.c:122)
==27702==    by 0x40157A: main (test.c:24)
==27702==
==27702== LEAK SUMMARY:
==27702==    definitely lost: 0 bytes in 0 blocks
==27702==    indirectly lost: 0 bytes in 0 blocks
==27702==      possibly lost: 0 bytes in 0 blocks
==27702==    still reachable: 2,076 bytes in 3 blocks
==27702==         suppressed: 0 bytes in 0 blocks
==27702==
==27702== For counts of detected and suppressed errors, rerun with: -v
==27702== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

zsszss0000

為啥提示找不到<glib.h>?

eglic_cu

zsszss0000 發(fā)表于 2014-12-19 08:47
為啥提示找不到?

直接 #include </usr/include/glib-2.0/glib.h>
或者 #include <glib-2.0/glib.h>

密林三木

glibc把malloc的內存不會歸還給系統(tǒng)的，你可以直接malloc然后free同樣會有這個問題。

myworkstation

回復 1# eglic_cu

試試這樣運行：G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind --db-attach=yes --tool=memcheck --leak-check=full --show-leak-kinds=all ./test.bin
因為glib有自己的內存管理策略，destory之類的函數(shù)并不表示把內存還給系統(tǒng)，也可以是還給glib的內存池，為了盡量消除glib自身內存策略的影響加上G_DEBUG=gc-friendly G_SLICE=always-malloc
   

eglic_cu

密林三木 發(fā)表于 2014-12-19 13:22
glibc把malloc的內存不會歸還給系統(tǒng)的，你可以直接malloc然后free同樣會有這個問題。

我用 g_malloc  和 g_free 沒有問題的呀？

eglic_cu

myworkstation 發(fā)表于 2014-12-19 14:32
回復 1# eglic_cu

試試這樣運行：G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind --db-attach=ye ...

那這樣的程序在服務器上長期用crond運行可靠嗎（每小時運行一次）？
會不會導致服務器內存耗盡？
如果是的話，有沒有什么辦法可以不重啟服務器來回收這些內存？

myworkstation

回復 7# eglic_cu


    進程退出時進程所占用的內存就被釋放了，這是系統(tǒng)的行為。不用擔心進程退出時有內存泄露。

eglic_cu

myworkstation 發(fā)表于 2014-12-20 10:27
回復 7# eglic_cu

好的，我在試試。

daxiguagg

hi.baidu.com/mcsekpfxhebikmq/item/b36fc5ee60ffcfd92a09a4bd
樓主可以看看這篇文章，手動試下就知道