4. [gtk] Speicher-/Speicherleckanalyse mit valgrind

[gtk] Speicher-/Speicherleckanalyse mit valgrind

  • M

    Hallo c-community,

    ich möchte für ein Programm eine grafische Oberfläche gestalten. Dafür schaue ich mir gerade gtk an. Wenn ich aber ein einfaches Programm (http://zetcode.com/tutorials/gtktutorial/firstprograms/) nachprogrammiere und es durch valgrind jage, sind dort schon Kilobyte große possible lost und still reachable Blöcke dabei.

    Hier das Beispiel:

    #include    <stdlib.h>
#include    <stdio.h>
#include    <gtk/gtk.h>

int main(int argc, char** argv){

    GtkWidget*   _loginWindow;

    gtk_init(&argc, &argv);

    _loginWindow    =   gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_widget_show(_loginWindow);

    g_signal_connect(_loginWindow, "destroy", G_CALLBACK(gtk_main_quit), NULL);

    gtk_main();

    return 1;
}

    Hier die dazu gehörige Ausgabe von valgrind:

    ==6120== Memcheck, a memory error detector
    ==6120== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
    ==6120== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
    ==6120== Command: ./GtkWindow
    ==6120==
    ==6120==
    ==6120== HEAP SUMMARY:
    ==6120== in use at exit: 970,974 bytes in 12,618 blocks
    ==6120== total heap usage: 77,220 allocs, 64,602 frees, 3,351,191 bytes allocated
    ==6120==
    ==6120== LEAK SUMMARY:
    ==6120== definitely lost: 0 bytes in 0 blocks
    ==6120== indirectly lost: 0 bytes in 0 blocks
    ==6120== possibly lost: 150,163 bytes in 919 blocks
    ==6120== still reachable: 820,811 bytes in 11,699 blocks
    ==6120== suppressed: 0 bytes in 0 blocks
    ==6120== Rerun with --leak-check=full to see details of leaked memory
    ==6120==
    ==6120== For counts of detected and suppressed errors, rerun with: -v
    ==6120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 169 from 10)

    mit --mem-check=full ist die Ausgabe länger als mein Terminalausgabespeicher von 512 Zeilen.

    Also wie kann man sinnvoll ein Programm mit gtk auf Speicherlecks überprüfen. Mit mem-check=full bezweifle ich, dass ich die Stellen identifizieren kann, welche auf Fehler in meinem Quellcode hinweisen. Wie löst ihr solche Problematik?

    Im Internet habe ich auch folgendes gefunden:

    G_SLICE=debug-blocks valgrind --tool=memcheck ./GtkWindow

    aber auch das reduziert die Ausgabe nicht segnifikant.

    MfG

    mirrowwinger

    0
  • Mod

    Hast du mal nach "valgrind gtk" gegoogelt? Google: valgrind gtk
    Alle Top-Treffer führen direkt zu ein und derselben Lösung.

    0
  • C

    Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C (alle ISO-Standards) in das Forum Andere GUIs - Qt, GTK+, wxWidgets verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
  • M

    Hallo nochmal,

    erstmal vielen Dank @SeppJ, trotz vorheriger suche habe ich nur die Hinweise auf

    G_SLICE=debug-blocks

    und

    G_DEBUG=resident-modules

    gefunden.

    Ich habe jetzt ein Wiki https://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto gefunden, welches alles schön beschreibt. ABER am Anfang dachte ich auch trotzdem noch, dass es irgendwo die Standard-gtk.supp-Datei gibt, mit der man sorgenfrei weiter programmieren kann. Leider habe ich diese nicht gefunden, was aber auch kein Abbruch ist. Ich habe mir selber eine project.supp Datei erstellt. Dabei bin ich wie folgt vorgegangen:

    1. Kompilieren des Quellcodes ohne suppressions mit --gen-suppressions=all -> mehrere Hundert Fehler
    2. unterster Fehler:
    {
    <insert_a_suppression_name_here>
    Memcheck:Leak
    fun:calloc
    obj:/lib/i386-linux-gnu/libglib-2.0.so.0.3200.4
    fun:g_malloc0
    fun:g_closure_new_simple
    fun:g_cclosure_new
    fun:g_signal_connect_data
    fun:gtk_box_pack
    fun:gtk_tooltip_init
    fun:g_type_create_instance
    obj:/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4
    fun:g_object_newv
    fun:g_object_new
    }
    diesen muss man sich anschauen und eine Art gemeinsammen Nenner finden. Ich habe hier folgende allgemeinere Version genommen:
    {
    g_object_new
    Memcheck:Leak
    ...
    fun:g_object_new*
    }
    und in meiner project.supp aufgenommen.
    3. Schritt 1 mit --suppressions=project.supp wiederholen -> deutlich weniger Fehler.
    4. wieder den untersten Fehler analysieren und neue Regel in project.supp aufnehmen.
    ...
    letzer schritt: Es sollte am Ende eure Fehler übrigbleiben.

    Falls ein erfahrenerer Programmierer einen Fehler in meinem Vorgehen findet, dann bitte mitteilen, freue mich über jeden Hinweis.

    Vielen Dank

    mirrowwwinger

    0
Anmelden zum Antworten