24

我正在使用许多 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 使用了内存池，正如这里所建议的那样吗？

我在用

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

2 回答 2

37

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

一种是内存池（新 glib 中的 g_slice，旧版本中的“mem chunks”）。这些是用于小型对象（例如列表节点）的专用分配器。您可以使用它来禁用切片分配器： G_SLICE=always-malloc valgrind myprogram

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

So together of course: G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind myprogram

A third issue is that GLib has global variables that are simply never freed but considered permanent program state. For example registered GType are never unloaded, and a few others. This is not fixable, but valgrind should show these global allocations as reachable, rather than as lost.

于 2010-11-23T14:28:53.670 回答
0

glib-2.12 已经很老了。

尝试获取 glib-2.24，编译并安装它（--prefix=/usr/local/glib-2.24例如），然后使用它来编译您的应用程序。

如果您仍然有这个，请尝试再次阅读 glib 手册 :)

于 2010-11-23T09:54:22.300 回答