2

この簡単なテスト プログラムを実行すると、Valgrind がメモリ リークを報告します。

#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 の回答 (これ、この他のもの、およびその他) を認識しています。

valgrindGLib の場合は、コマンドの前にプレフィックスを付けるだけで十分G_DEBUG=gc-friendly G_SLICE=always-mallocです (ただし、「まだ到達可能な」リークがいくつかありますが、それらが GLib からのものである場合は無視します)。

ただし、この小さなプログラムでは、多くの「失われた可能性がある」リークが発生します。G_DEBUG=resident-modules(suggested here ) やG_SLICE=debug-blocks(suggested here )などの他のプレフィックスも試しましたが、「失われた可能性がある」リークが残っています。また、いくつかのGNOME 抑制、つまり 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) を使用しています。

前もって感謝します。

4

2 に答える 2

1

私が見る「失われた可能性がある」ブロックはすべて、型が GObject に登録されたときのものです。これらは実際にはまだ到達可能です。valgrind がそれらに到達する方法を理解していないだけです (確かに少し奇妙です。混乱していることを valgrind のせいにしません)。到達可能」。

コードに問題はなく、glib に実際にリークはありません。抑制ファイルを使用する必要があります。

于 2014-10-27T02:55:52.907 に答える
0

gdk_pixbuf_new_from_file() が何らかの理由 (たとえば、ファイルが存在しない) で失敗した場合、「buf」は NULL に割り当てられ、「err」を介してエラーが返されます。次に g_assert_no_error(err) はプログラムを終了しますが、「err」が指すメモリを解放しません。自分でエラーを管理し、"err" を g_free_error(err) で解放した方がよいでしょう。「gdk_pixbuf_new_from_file」を呼び出した後、残りのコードを削除して次のように置き換え、Valgrind の結果として何が得られるかを確認します。

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

ところで、私は Valgrind にあまり詳しくありません。メモリ リークの可能性を指摘しているだけです。その時点でプログラムは終了し、カーネルはプログラムに割り当てられたメモリ ブロックを再利用するのに十分なほどスマートである可能性があります。

于 2014-10-24T21:17:26.370 に答える