Valgrind 报告内存“可能丢失”使用 glib 数据类型时
我正在开发一个使用许多 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 (Red Hat 4.1.2-48)
- CentOS 版本 5.5 (最终版)
I'm developing a library using a number of glib datastructures (GHashTable, GSList etc.). I've been checking my code frequently for memory leaks using valgrind. Most of the issues valgrind points out are quite easy to fix, however there's a few that I can't figure out.
All of these are reported as 'possibly lost'.
At the top of the valgrind stacktrace, I always find the same 4 libraries:
==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)
Further down in the call stack, there is always a call to a glib function, such as g_key_file_new(), g_slist_prepend(), g_strsplit(), g_key_file_load_from_file(), g_file_get_contents().
My questions are:
Has anyone come across this and found a way around it?
Or is this something I can disregard? Is it due to glib using memory pools, as suggested here?
I am using
- valgrind-3.5.0
- glib-2.12.3
- gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
- CentOS release 5.5 (Final)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
GLib 有一些让 Valgrind 感到困惑的功能。
一种是内存池（较新的 glib 中的 g_slice，较旧的 glib 中的“mem chunks”）。这些是用于小对象（例如列表节点）的专用分配器。您可以使用它来禁用切片分配器：
G_SLICE=always-malloc valgrind myprogram第二个问题是，有时 GLib 会避免初始化新内存或在释放的切片/块中保留死指针。您可以通过以下方式修复此问题：
G_DEBUG=gc-Friendly valgrind myprogram当然一起：
G_DEBUG=gc-Friendly G_SLICE=always-malloc valgrind myprogram第三个问题是 GLib 的全局变量永远不会被释放，但被视为永久程序状态。例如，注册的 GType 永远不会被卸载，还有其他一些。这是无法修复的，但 valgrind 应该将这些全局分配显示为可达，而不是丢失。
GLib has a few features that confuse Valgrind.
One is memory pools (g_slice in newer glib, "mem chunks" in older). These are specialized allocators used for small objects such as list nodes. You can use this to disable the slice allocator:
G_SLICE=always-malloc valgrind myprogramA second issue is that sometimes GLib would avoid initializing new memory or keep dead pointers in freed slices/chunks. You can fix this with:
G_DEBUG=gc-friendly valgrind myprogramSo together of course:
G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind myprogramA 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.
glib-2.12 已经很老了。
尝试获取 glib-2.24，编译并安装它（例如使用 --prefix=/usr/local/glib-2.24），然后使用它来编译您的应用程序。
如果你仍然有这个问题，请尝试再次阅读 glib 手册:)
glib-2.12 is quite old.
Try getting glib-2.24, compile and install it (with --prefix=/usr/local/glib-2.24 for example) then use it to compile your application.
If you still have this, try to read the glib manual again :)