当前位置:  开发笔记 > 运维 > 正文

Valgrind报告使用glib数据类型时内存"可能已丢失"

如何解决《Valgrind报告使用glib数据类型时内存"可能已丢失"》经验,为你挑选了1个好方法。

我正在使用许多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

巧舌如簧-2.12.3

gcc(GCC)4.1.2 20080704(Red Hat 4.1.2-48)

CentOS 5.5版(最终版)

Havoc P.. 35

GLib有一些让Valgrind迷惑的功能.

一个是内存池(较新的glib中的g_slice,较旧的"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应该将这些全局分配显示为可达,而不是丢失.



1> Havoc P..:

GLib有一些让Valgrind迷惑的功能.

一个是内存池(较新的glib中的g_slice,较旧的"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应该将这些全局分配显示为可达,而不是丢失.


是的,例如在gconvert.c中"静态GHashTable*iconv_cache"等(只是一个例子)
推荐阅读
Chloemw
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有