Speicherlecks in GTK hallo_world Programm

Question

Also ... Ich versuche, einige Speicherlecks von meinem GTK + 3 Programm zu beseitigen. Ich denke, es wäre eine gute Idee, auf ein paar einfache Beispiele zurückzuschauen, um zu sehen, ob es ein paar Aufräumarbeiten gibt, die ich vergesse, aber das Programm hello_world, das in der Dokumentation enthalten ist, hat auch Lecks. (Valgrind-Ausgabe unten).

Sind diese Leckagen akzeptabel? Wenn ja, gibt es eine andere Anwendung, die ich verwenden sollte, um GTK-Programme zu debuggen?

==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) 

Code:

#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; 
} 

Answer 1

Diese Antwort wird aus den Antworten auf die gleiche Frage zusammengestellt (auf dem heute nicht mehr existierenden www.gtkforums.com).

GTK + ist ziemlich faul, wenn es darum geht, interne Puffer zu reservieren, die für die Lebensdauer der Anwendung benötigt werden. Zum Beispiel kann es während der Initialisierung einen Speicherbereich für eine Nachschlagetabelle zuweisen, der für die Lebensdauer der Anwendung benötigt wird. GTK + wird dies dann niemals rückgängig machen. Für Valgrind sieht das wie ein Speicherleck aus (was technisch so ist), aber als eine Optimierung hebt GTK + es nicht auf, da es während des Application-Exits freigegeben wird und daher kein Fehler ist. Aus diesem Grund benötigen Sie Unterdrückungsdateien, damit Valgrind diese ignorieren kann. Das Problem ist, dass Sie diese mit den meisten GTK + Versionsänderungen ändern müssen.

Repository von Unterdrückung Dateien: https://github.com/dtrebbien/GNOME.supp

Nach dem Repository klonen, können Sie die Unterdrückung Dateien erzeugen (auch mit glib kommt, gdk und andere) mit „make“ und dann verweisen valgrind ihnen wie also:

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

Answer 2

Für Debug-glib/gtk-Programme würde ich diesen Befehl verwenden:

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

G_SLICE = Debug-Blöcke werden gtk fortschrittliche Speicherverwaltung deaktivieren valgrind zu ermöglichen um korrekte Ergebnisse zu zeigen.

--leak-check = full zeigt Stack-Traces für die ausgelaufenen Speicherblöcke an.

Sie können auch --show-reachable = yes verwenden, um Stack-Traces für alle Speicherblöcke anzuzeigen, die beim Beenden des Programms nicht frei waren.

Es gibt auch das Tool "massif valgrind", das die Speichernutzung verfolgt, um anzuzeigen, welche Teile des Programms den meisten Speicher verwenden.

Run Programm unter Massiv:

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

Ergebnisse anzeigen:

ms_print massif.out.<pid>