glib2實際上與ALWAYS-MALLOC泄漏內存？

這個問題不許多其他的副本，bekause我做使用G_DEBUG=gc-friendly和G_SLICE=always-malloc 這是源代碼：glib2實際上與ALWAYS-MALLOC泄漏內存？

#include <glib.h> 

int main (int argc, char *argv[]) 
{ 
    GHashTable *ht; 
    ht=g_hash_table_new(g_str_hash,g_str_equal); 
    g_hash_table_insert(ht,"foo","bar"); 
    g_hash_table_destroy(ht); 
    return 0; 
}

而且這裏的valgrind對這個代碼的輸出：

# G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind --leak-check=full --show-reachable=yes ./test_vg 
==1880== Memcheck, a memory error detector 
==1880== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. 
==1880== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info 
==1880== Command: ./test_vg 
==1880== 
==1880== 
==1880== HEAP SUMMARY: 
==1880==  in use at exit: 1,260 bytes in 3 blocks 
==1880== total heap usage: 5 allocs, 2 frees, 1,524 bytes allocated 
==1880== 
==1880== 252 bytes in 1 blocks are still reachable in loss record 1 of 3 
==1880== at 0x4A04A28: calloc (vg_replace_malloc.c:467) 
==1880== by 0x35C8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x35C8255742: ??? (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x35C825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x35C822B1D2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x400671: main (in /home/data/test_vg) 
==1880== 
==1880== 504 bytes in 1 blocks are still reachable in loss record 2 of 3 
==1880== at 0x4A04A28: calloc (vg_replace_malloc.c:467) 
==1880== by 0x35C8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x35C8255722: ??? (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x35C825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x35C822B1D2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x400671: main (in /home/data/test_vg) 
==1880== 
==1880== 504 bytes in 1 blocks are still reachable in loss record 3 of 3 
==1880== at 0x4A04A28: calloc (vg_replace_malloc.c:467) 
==1880== by 0x35C8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x35C825578B: ??? (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x35C825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x35C822B1D2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.2200.5) 
==1880== by 0x400671: main (in /home/data/test_vg) 
==1880== 
==1880== LEAK SUMMARY: 
==1880== definitely lost: 0 bytes in 0 blocks 
==1880== indirectly lost: 0 bytes in 0 blocks 
==1880==  possibly lost: 0 bytes in 0 blocks 
==1880== still reachable: 1,260 bytes in 3 blocks 
==1880==   suppressed: 0 bytes in 0 blocks 
==1880== 
==1880== For counts of detected and suppressed errors, rerun with: -v 
==1880== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

它是內存泄漏嗎？

來源

2012-09-12 Pupkov-Zadnij

您從未從散列表中刪除元素！另外，「仍然可以」並不是真正的泄漏;這更像是一個粗心大意。 –

@KerrekSB我想我不需要，因爲它們被分配到棧中，而g_hash_table_destroy必須完成這項工作。 –

@KerrekSB不止於此，我只是添加了g_hash_table_remove（ht，「foo」），結果是一樣的。 –

當我使用Valgrind檢查GLIB2程序時，我總是遇到很多虛假的和無法訪問的項目項目。在你的情況下，泄漏似乎來自哈希表的創建。我會創建第二個散列表，看看你是否得到額外的塊（否則，它可能是一些內部初始化在glib中）。

使用Valgrind的與GLIB和GTK的一些注意事項在這裏wiki.gnome.org

來源

2013-11-08 18:22:42 Wadester

要回答你的問題：不，這不是傳統意義上的內存泄漏。你的代碼很好。

即使您使用G_DEBUG=gc-friendly和G_SLICE=always-malloc，GLib始終會在退出時保留「仍可到達」內存。不要使用--show-reachable=yes選項，否則使用GLib時總是會產生污染的Valgrind輸出。但是，如果爲靜態或全局變量（「內存可用」）分配了保存指針的內存，請小心。在這種情況下，您最終可能會忽視自己的「真實」泄漏。

來源

2014-08-16 18:00:43 faken

glib2實際上與ALWAYS-MALLOC泄漏內存？

回答

相關問題