valgrind 向 gtk init 调用显示的内存泄漏答案

【问题标题】：memory leaks shown by valgrind to gtk init callvalgrind 向 gtk init 调用显示的内存泄漏
【发布时间】：2013-06-01 11:25:06
【问题描述】：

我正在尝试检查我的代码中的内存泄漏，而 valgrind 显示了许多错误。因为我以前从未使用过 valgrind，所以我需要帮助。首先，我专注于默认的 gtk 调用。按照编码，内存是从 mkbib.c 的第 140 行泄漏的。但是第 140 行只是

gtk_init(&argc, &argv);

我用过

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck 
--leak-check=full --leak-resolution=high --num-callers=20 
--log-file=vgdump --suppressions=gtk.suppression ./mkbib

其中与 gtk.suppression 一起取自 valgrind-gnome Live

==28420== 16 bytes in 1 blocks are definitely lost in loss record 2,413 of 10,955
==28420==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==28420==    by 0x310CA4D68E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311C611176: ??? (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420==    by 0x311C60C19D: atk_bridge_adaptor_init (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420==    by 0x311D50257B: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x403F65: main (mkbib.c:140)
==28420== 
==28420== 16 bytes in 1 blocks are definitely lost in loss record 2,414 of 10,955
==28420==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==28420==    by 0x310CA4D68E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311C611176: ??? (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420==    by 0x311C60C1DD: atk_bridge_adaptor_init (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420==    by 0x311D50257B: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x403F65: main (mkbib.c:140)
==28420== 
==28420== 24 bytes in 1 blocks are possibly lost in loss record 3,468 of 10,955
==28420==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==28420==    by 0x310CA4D68E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x310CA63F65: g_memdup (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x310D22D274: ??? (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x310D22DFCC: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x311D5022C7: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311A6154C8: atk_add_focus_tracker (in /usr/lib64/libatk-1.0.so.0.20609.1)
==28420==    by 0x311D502567: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x403F65: main (mkbib.c:140)
==28420== 
==28420== 24 bytes in 1 blocks are possibly lost in loss record 3,469 of 10,955
==28420==    at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==28420==    by 0x310CA4D6E6: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x310D22DF00: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x310D22DD4E: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x310D21E7BF: g_param_spec_flags (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x311D4C27BB: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310D22E0B5: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x311D5022C7: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311A6154C8: atk_add_focus_tracker (in /usr/lib64/libatk-1.0.so.0.20609.1)
==28420==    by 0x311D502567: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x403F65: main (mkbib.c:140)

我发现一些讨论认为 valgrind 不能很好地检测 gtk 中的内存泄漏。这是我应该忽略的这种情况之一吗？还是我错过了什么？

我的系统是：

gtk3-devel-3.6.4-1.fc18.x86_64
valgrind-3.8.1-9.fc18.x86_64
gcc(GCC) 4.7.2 20121109

【问题讨论】：

标签： memory-leaks gtk valgrind

【解决方案1】：

目前，您应该专注于在您的代码部分中明确检测到的泄漏。 Valgrind 经常在您无法修改的外部组件上发现漏洞，甚至是商业库。您可以查阅忽略文件的文档，它们会抑制来自某些库的错误输出： http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress

【讨论】：

感谢您的评论。但正如你所看到的，我已经按照 gtk 本身的建议使用了抑制。但这些漏洞仍然存在。
我查看了抑制文件，虽然我不是专家，但我认为您的错误不在其中。它没有包含正确库的行，尽管有包含正确函数的行，但在另一个库中。也许您可以生成另一个抑制文件或将所需的抑制添加到现有文件中。

【解决方案2】：

尝试将抑制文件修改为更通用，摘录示例： ... obj:/usr/lib64/libgtk* (issue seems to apply to any gtk version, including gtk-2) fun:g_option_context_parse fun:gtk_parse_args (or could just use "...") fun:gtk_init* (also applies to gtk_init_check)

【讨论】：