c - 使用 glib 数据类型时，Valgrind 报告内存 'possibly lost'

Question

我正在开发一个使用大量 glib 数据结构(GHashTable、GSList 等)的库。我一直在使用 valgrind 经常检查我的代码是否存在内存泄漏。 valgrind 指出的大多数问题都很容易解决，但有一些我无法弄清楚。

所有这些都被报告为“可能丢失”。

在 valgrind 堆栈跟踪的顶部，我总是找到相同的 4 个库:

==29997== 1,512 bytes in 3 blocks are possibly lost in loss record 24 of 25
==29997==    at 0x4004B11: memalign (vg_replace_malloc.c:532)
==29997==    by 0x4004B6B: posix_memalign (vg_replace_malloc.c:660)
==29997==    by 0x5E9AC4: ??? (in /lib/libglib-2.0.so.0.1200.3)
==29997==    by 0x5EA4FE: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.3)

在调用堆栈的更下方，总是有对 glib 函数的调用，例如 g_key_file_new()、g_slist_prepend()、g_strsplit()、g_key_file_load_from_file()、g_file_get_contents()。

我的问题是:

• 有没有人遇到过这个问题并找到解决方法？

• 或者这是我可以忽略的事情？是否是由于 glib 使用内存池，如建议的那样 here ？

我正在使用

• valgrind-3.5.0
• glib-2.12.3
• 海湾合作委员会 (GCC) 4.1.2 20080704(红帽 4.1.2-48)
• CentOS 5.5 版(最终版)

Answer 1

GLib 有一些让 Valgrind 感到困惑的特性。

一个是内存池(较新的 glib 中的 g_slice，旧的“mem chunks”)。这些是专门用于小对象(例如列表节点)的分配器。您可以使用它来禁用切片分配器:G_SLICE=always-malloc valgrind myprogram

第二个问题是，有时 GLib 会避免初始化新内存或在释放的切片/ block 中保留死指针。您可以使用以下方法解决此问题:G_DEBUG=gc-friendly valgrind myprogram

所以当然在一起:G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind myprogram

第三个问题是 GLib 具有永远不会释放但被视为永久程序状态的全局变量。例如注册的 GType 永远不会被卸载，还有一些其他的。这是不可修复的，但 valgrind 应该将这些全局分配显示为可达，而不是丢失。