Détection de fuites mémoire avec Valgrind
Salut,
J'envisage de me servir de GLIB pour ses commodités ( conteneurs etc... )
Malheureusement si la documentation est bien faîte, elle le serait encore mieux avec quelques exemples.
voiçi le problème :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
#include <stdlib.h>
#include <glib-2.0/glib.h>
int main (int argc, char **argv)
{
gchar * n = "toto.txt" ;
gchar * z = NULL ;
gboolean res = g_file_get_contents( n, &z, NULL, NULL );
if( res != FALSE )
g_printf("%s\n", z ) ;
else
g_printf("Erreur \n") ;
if( z )
{ g_free( z ) ;
z = NULL ;
}
return 0 ;
} |
Tout se passe très bien. Mais en déboguant avec valgrind (linux ), ce dernier m'indique qu'il y des pertes de mémoire.
Je dois faire une erreur quelque part, mais où ?
Premier programme avec GTK
Bonjour,
Voiçi le code source, et le résultat du debugger valgrind ( linux ).
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
#include <stdlib.h>
#include <gtk/gtk.h>
int main (int argc, char **argv)
{
GtkWidget *win, *but;
gtk_init( &argc, &argv );
win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (win, "delete-event",
G_CALLBACK (gtk_true), NULL);
g_signal_connect (win, "destroy",
G_CALLBACK (gtk_main_quit), NULL);
but = gtk_button_new_with_label ("Close yourself. I à mean it!");
g_signal_connect_swapped (but, "clicked",
G_CALLBACK (gtk_object_destroy), win);
gtk_container_add (GTK_CONTAINER (win), but);
gtk_widget_show_all (win);
gtk_main ();
return 0;
} |
Le résultat de valgrind donne :
Citation:
ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 83 from 1)
==4874== malloc/free: in use at exit: 1,096,962 bytes in 8,263 blocks.
==4874== malloc/free: 23,225 allocs, 14,962 frees, 3,314,462 bytes allocated.
==4874== For counts of detected errors, rerun with: -v
==4874== searching for pointers to 8,263 not-freed blocks.
==4874== checked 1,358,800 bytes.
==4874==
==4874== LEAK SUMMARY:
==4874== definitely lost: 20,450 bytes in 692 blocks.
==4874== possibly lost: 69,844 bytes in 66 blocks.
==4874== still reachable: 1,006,668 bytes in 7,505 blocks.
==4874== suppressed: 0 bytes in 0 blocks.
==4874== Use --leak-check=full to see details of leaked memory.
Il y a un truc qui ne va pas ? A votre avis ?
