2013-05-20 69 views
7

私はGTK + 3プログラムからメモリリークを取り除こうとしています。いくつかの簡単な例を振り返って、私が忘れているクリーンアップがあるかどうかを確認することは良い考えですが、ドキュメントに提供されているhello_worldプログラムにもリークがあります。 (下のValgrind出力)。GTK hello_worldプログラムのメモリリーク

これらのリークは受け入れられますか?もしそうなら、私はGTKプログラムをデバッグするために使用すべき他のアプリケーションがありますか?

==13717== Memcheck, a memory error detector 
==13717== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. 
==13717== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info 
==13717== Command: ./a 
==13717== 
Hello World 
==13717== 
==13717== HEAP SUMMARY: 
==13717==  in use at exit: 1,578,162 bytes in 11,614 blocks 
==13717== total heap usage: 45,699 allocs, 34,085 frees, 6,461,970 bytes allocated 
==13717== 
==13717== LEAK SUMMARY: 
==13717== definitely lost: 2,560 bytes in 5 blocks 
==13717== indirectly lost: 6,656 bytes in 207 blocks 
==13717==  possibly lost: 363,228 bytes in 1,937 blocks 
==13717== still reachable: 1,205,718 bytes in 9,465 blocks 
==13717==   suppressed: 0 bytes in 0 blocks 
==13717== Rerun with --leak-check=full to see details of leaked memory 
==13717== 
==13717== For counts of detected and suppressed errors, rerun with: -v 
==13717== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) 

コード:valgrindのを許可するようにGTKの先進的なメモリ管理をオフにします

G_SLICE=debug-blocks valgrind --tool=memcheck --leak-check=full <gtk program> 

G_SLICE =デバッグブロック:私は、このコマンドを使用しますglibの/ GTKプログラムをデバッグするための

#include <gtk/gtk.h> 

/* This is a callback function. The data arguments are ignored 
* in this example. More on callbacks below. 
*/ 
static void 
print_hello (GtkWidget *widget, 
      gpointer data) 
{ 
    g_print ("Hello World\n"); 
} 

static gboolean 
on_delete_event (GtkWidget *widget, 
       GdkEvent *event, 
       gpointer data) 
{ 
    /* If you return FALSE in the "delete_event" signal handler, 
    * GTK will emit the "destroy" signal. Returning TRUE means 
    * you don't want the window to be destroyed. 
    * 
    * This is useful for popping up 'are you sure you want to quit?' 
    * type dialogs. 
    */ 

    g_print ("delete event occurred\n"); 

    return TRUE; 
} 

int 
main (int argc, 
     char *argv[]) 
{ 
    /* GtkWidget is the storage type for widgets */ 
    GtkWidget *window; 
    GtkWidget *button; 

    /* This is called in all GTK applications. Arguments are parsed 
    * from the command line and are returned to the application. 
    */ 
    gtk_init (&argc, &argv); 

    /* create a new window, and set its title */ 
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL); 
    gtk_window_set_title (GTK_WINDOW (window), "Hello"); 

    /* When the window emits the "delete-event" signal (which is emitted 
    * by GTK+ in response to an event coming from the window manager, 
    * usually as a result of clicking the "close" window control), we 
    * ask it to call the on_delete_event() function as defined above. 
    * 
    * The data passed to the callback function is NULL and is ignored 
    * in the callback function. 
    */ 
    g_signal_connect (window, "delete-event", G_CALLBACK (on_delete_event), NULL); 

    /* Here we connect the "destroy" event to the gtk_main_quit() function. 
    * 
    * This signal is emitted when we call gtk_widget_destroy() on the window, 
    * or if we return FALSE in the "delete_event" callback. 
    */ 
    g_signal_connect (window, "destroy", G_CALLBACK (gtk_main_quit), NULL); 

    /* Sets the border width of the window. */ 
    gtk_container_set_border_width (GTK_CONTAINER (window), 10); 

    /* Creates a new button with the label "Hello World". */ 
    button = gtk_button_new_with_label ("Hello World"); 

    /* When the button receives the "clicked" signal, it will call the 
    * function print_hello() passing it NULL as its argument. 
    * 
    * The print_hello() function is defined above. 
    */ 
    g_signal_connect (button, "clicked", G_CALLBACK (print_hello), NULL); 

    /* The g_signal_connect_swapped() function will connect the "clicked" signal 
    * of the button to the gtk_widget_destroy() function; instead of calling it 
    * using the button as its argument, it will swap it with the user data 
    * argument. This will cause the window to be destroyed by calling 
    * gtk_widget_destroy() on the window. 
    */ 
    g_signal_connect_swapped (button, "clicked", G_CALLBACK (gtk_widget_destroy), window); 

    /* This packs the button into the window. A GtkWindow inherits from GtkBin, 
    * which is a special container that can only have one child 
    */ 
    gtk_container_add (GTK_CONTAINER (window), button); 

    /* The final step is to display this newly created widget... */ 
    gtk_widget_show (button); 

    /* ... and the window */ 
    gtk_widget_show (window); 

    /* All GTK applications must have a gtk_main(). Control ends here 
    * and waits for an event to occur (like a key press or a mouse event), 
    * until gtk_main_quit() is called. 
    */ 
    gtk_main(); 

    return 0; 
} 

答えて

4

この回答は(www.gtkforums.com今は亡き上)同じ質問への回答からコンパイルされます。

GTK +は、アプリケーションのライフタイムに必要な内部バッファの割り当てと割り当て解除にかなり怠惰です。例えば、アプリケーションの寿命のために必要とされる、初期化中にルックアップテーブルのためのメモリ領域を割り当てることができる。 GTK +はこれを決して割り当て解除しません。 Valgrindの場合、これはメモリリークのように見えますが(技術的にはそうですが)、最適化としてGTK +はアプリケーションの終了時に割り当てが解除されるため、エラーではなく、割り当てを解除しません。 Valgrindがこれらを無視できるように抑制ファイルが必要なのはこのためです。問題は、ほとんどのGTK +バージョンの変更でこれらを変更する必要があることです。

抑制ファイルのリポジトリ: https://github.com/dtrebbien/GNOME.supp

リポジトリをクローンしたら、抑制ファイルを生成することができます(また、GDK、glibのが付属しており、他の人)「作る」と、その後のようにそれらをvalgrindのを参照してくださいとso:

valgrind ./a --suppression=/path/to/gtk3.supp 
+0

私はそれを確実に使用する方法を理解していません。 'gcc -g -Wall $(pkg-config --cflags gtk + -3.0)bill.c $(pkg-config --libs gtk + -3.0)-o bill'であなたのコードをコンパイルしました。私はdtrebbien/GNOME.suppをビルドし、すべての '* supp'ファイルを'/usr/lib/valgrind/'にインストールしました。あなたの例を 'valgrind -v --suppressions =/usr/lib/valgrind/{base、glib、gio、gdk、gtk、gtk3} .supp。/ bill'で実行しましたが、valgrindはエラーを表示します。もっと説明してください(Debian/Sid/x86-64のGTK3.22、valgrind 3.12) –

1

正しい結果を表示する。

--leak-check = fullは、リークされたメモリブロックのスタックトレースを表示します。

--show-reachable = yesを使用すると、プログラムの終了時に空き状態になっていないすべてのメモリブロックのスタックトレースを表示することもできます。

メモリの使用状況を追跡し、プログラムのどの部分が最もメモリを使用しているかを示すマージフvalgrindツールもあります。山塊の下

実行プログラム:

G_SLICE=always-malloc valgrind --tool=massif --detailed-freq=2 --max-snapshots=400 --num-callers=20 <gtk program> 

表示結果は:

ms_print massif.out.<pid> 
+1

ValgrindはまだG_SLICE = debug-blocksで失われた2560ブロックを示しています。私は痕跡を見て、彼らがどこから来ているのかを知ることができるかどうかを見ます。 – Bill

関連する問題