glib2 是否真的使用 ALWAYS-MALLOC 泄漏内存？答案

【问题标题】：Does glib2 actually leak memory with ALWAYS-MALLOC?glib2 是否真的使用 ALWAYS-MALLOC 泄漏内存？
【发布时间】：2019-08-20 14:49:59
【问题描述】：

这个问题不是与许多其他问题的重复，因为我确实使用G_DEBUG=gc-friendly和G_SLICE=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)

是内存泄漏吗？

【问题讨论】：

您从未从哈希表中删除元素！此外，“仍然可以访问”并不是真正的泄漏。这更像是一种粗心。
@KerrekSB 我想我不需要，因为它们是在堆栈上分配的，而 g_hash_table_destroy 必须完成这项工作。
@KerrekSB 不止如此，我只是添加了g_hash_table_remove(ht,"foo")，结果是一样的。
您是否也尝试过按照建议的here 使用resident-modules？
这是与Valgrind reports memory 'possibly lost' when using glib data types 的重复：只需检查接受的答案即可。

标签： c memory-leaks valgrind glib

【解决方案1】：

回答您的问题：不，这不是传统意义上的内存泄漏。你的代码很好。

即使你使用G_DEBUG=gc-friendly 和G_SLICE=always-malloc，GLib 总是在退出时留下“仍然可以访问”的内存。不要使用--show-reachable=yes 选项，否则在使用 GLib 时，Valgrind 输出总是会受到污染。但是，如果您分配在静态或全局变量中保存指针的内存（“仍可访问”内存），请小心。在这种情况下，您最终可能会忽略自己的“真实”泄漏。

【讨论】：

【解决方案2】：

在使用 Valgrind 检查 GLib 2 程序时，我总是遇到很多错误和无法访问的项目。在您的情况下，泄漏似乎来自哈希表的创建。我会创建第二个哈希表，看看你是否得到了额外的块（否则，它可能是 GLib 中的一些内部初始化）。

关于将 Valgrind 与 GLIB 和 GTK are at wiki.gnome.org 结合使用的一些注意事项。

【讨论】：

【解决方案3】：

尝试将--suppressions=/usr/share/glib-2.0/valgrind/glib.supp 传递给valgrind。它抑制了来自 GLib 的误报。

【讨论】：