C Valgrind报告内存'；可能丢失'；使用glib数据类型时

我正在使用一些glib数据结构（GHashTable、GSList等）开发一个库。我经常使用valgrind检查代码中的内存泄漏。valgrind指出的大多数问题都很容易解决，但也有一些问题我无法解决

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

在valgrind stacktrace的顶部，我总能找到相同的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使用内存池造成的

我正在使用

• valgrind-3.5.0
• glib-2.12.3
• gcc（gcc）4.1.2 20080704（红帽4.1.2-48）
• CentOS 5.5版（最终版）

---

glib-2.12已经很老了
尝试获取glib-2.24，编译并安装它（例如使用--prefix=/usr/local/glib-2.24），然后使用它编译应用程序

---

如果您仍有此功能，请尝试再次阅读glib手册：）
glib有一些让Valgrind感到困惑的功能
一个是内存池（在较新的glib中是g_片，在较旧的glib中是mem块）。这些是用于列表节点等小对象的专用分配器。您可以使用此选项禁用切片分配器：

G_SLICE=总是malloc valgrind myprogram

第二个问题是，GLib有时会避免初始化新内存或在释放的片/块中保留死指针。您可以通过以下方法解决此问题：

G_DEBUG=gc-friendly-valgrind-myprogram

因此，我们当然要一起：

G_DEBUG=gc友好的G_SLICE=always malloc valgrind myprogram

---

第三个问题是GLib具有全局变量，这些变量永远不会被释放，而是被认为是永久的程序状态。例如，注册的GType永远不会卸载，还有一些其他的。这是不可修复的，但valgrind应该将这些全局分配显示为可访问的，而不是丢失的。
不幸的是，我一直使用这个版本的glib，因为我正在开发的软件将在托管服务器上运行，2.12是默认版本运行带有G_SLICE=always malloc的程序时不会显示内存丢失，这证实了我的怀疑，所有（可能的）内存丢失都是由于内存池造成的。感谢浩劫P给出了清晰的答案。浩劫你能确认你关于全局变量的陈述对于GLib 2.32仍然是正确的吗？谢谢是的，例如在gconvert.c“静态GHashTable*iconv_缓存”等中（仅一个示例）