Question

当我运行这个简单的测试程序时，Valgrind会报告memory leak：

#include <gdk-pixbuf/gdk-pixbuf.h>
int main() {
    GdkPixbuf* buf;
    GError* err = NULL;
    buf = gdk_pixbuf_new_from_file("test.jpg", &err);
    g_assert_no_error(err);
    g_object_unref(buf);
    return 0;
}

我知道有关Valgrind和GLib / GDK / GTK以及有关此问题的几个StackOverflow答案（例如this one，this other one和其他人）的问题。

对于GLib，它足以在valgrind命令前加上G_DEBUG=gc-friendly G_SLICE=always-malloc（尽管我仍然有一些“仍然可以检测到的”泄漏，如果它们来自GLib，我会忽略它）。

但是，通过这个小程序，我得到了很多"possibly lost" leaks。我还尝试了其他前缀，例如G_DEBUG=resident-modules（建议here）和G_SLICE=debug-blocks（建议here），但“可能丢失”的泄漏仍然存在。我也尝试了几个GNOME suppressions，即GDK，但无济于事。

我的问题是：这是我为此案例创建抑制文件的唯一替代方法，还是代码有问题？

该程序编译为：

gcc -Wall -std=c99 -g -pedantic `pkg-config --cflags glib-2.0 gdk-pixbuf-2.0` pixbuf.c -o pixbuf `pkg-config --libs glib-2.0 gdk-pixbuf-2.0`

我正在使用GDK-Pixbuf 2.30.7（Ubuntu 14.04）。

提前致谢。

Answer 1

如果gdk_pixbuf_new_from_file（）由于某种原因失败（例如，文件不存在），＆＃34; buf＆＃34;将被分配为NULL，错误将通过＆＃34; err＆＃34;返回。然后g_assert_no_error（错误）将终止该程序，但它不会释放内存和＃34;错误＆＃34;点。如果你自己管理错误并且免费“错误”，那么你会感觉更好。使用g_free_error（错误）。调用＆＃34; gdk_pixbuf_new_from_file＆＃34;删除剩下的代码，用以下代码替换它，看看你从Valgrind得到的结果：

if (!buf) {
    g_printerr("%s\n", err->message);
    g_free_error(err);
}
else {
    g_object_unref(buf);
}

顺便说一句，我对Valgrind不太熟悉，我只是指出了可能的内存泄漏。虽然在那时你的程序已经终止，并且内核可能足够聪明，可以回收它分配给程序的内存块。

Answer 2

我看到的所有“可能丢失”的块都是从GObject注册的类型。这些真的仍然可以达到，只是valgrind不明白如何到达它们（不可否认它有点奇怪，我不会责怪valgrind被混淆），所以它报告它们“可能丢失”而不是“仍然可达”的。

您的代码没有任何问题，并且glib中没有真正的泄漏。您应该使用抑制文件。

gdk_pixbuf_new_from_file（）中的内存泄漏

2 个答案: