Discussion :

[dj.motte]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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ù ?

[souviron34]

tu fais un getcontent qui va stocker le fichier dans z (et donc fais de l'allocation dynamique).

Maisntu ne libères pas z avant de sortir du programme

[dj.motte]

Salut,

Pourtant j'ai bien dans mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if( z )  
  { g_free( z ) ;
    z = NULL ;
  }

Il peut-être faire autrement ?

[Emmanuel Delahaye]

tu fais un getcontent qui va stocker le fichier dans z (et donc fais de l'allocation dynamique).

Maisntu ne libères pas z avant de sortir du programme

Ben si, c'est fait ...

Je ne vois pas bien quel est le problème de ce code. A moins que les 2 paramètres à NULL n'introduisent un comportement indéterminé.

-> La Doc.

[gege2061]

Bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#include <glib-2.0/glib.h>

Ton compilateur est mal configuré, il faut juste écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#include <glib.h>

A moins que les 2 paramètres à NULL n'introduisent un comportement indéterminé.

Non, c'est un comportement normal : g_file_get_contents

Je dois faire une erreur quelque part, mais où ?

valgrind doit t'indiquer d'où vient le problème, poste le message

[dj.motte]

Bonjour,

Voilà ce que dit valgrind :

ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1)
==4912== malloc/free: in use at exit: 5,676 bytes in 23 blocks.
==4912== malloc/free: 31 allocs, 8 frees, 15,626 bytes allocated.
==4912== For counts of detected errors, rerun with: -v
==4912== searching for pointers to 23 not-freed blocks.
==4912== checked 89,684 bytes.
==4912==
==4912== LEAK SUMMARY:
==4912== definitely lost: 0 bytes in 0 blocks.
==4912== possibly lost: 744 bytes in 3 blocks.
==4912== still reachable: 4,932 bytes in 20 blocks.
==4912== suppressed: 0 bytes in 0 blocks.
==4912== Reachable blocks (those to which a pointer was found) are not shown.
==4912== To see them, rerun with: --show-reachable=yes

Apparemment pas d'erreur, mais des "possibly lost", ou "still reachables".

Plus précis, mais je n'y comprends pas grand chose :

==5004==
==5004== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1)
--5004--
--5004-- supp: 19 Fedora-Core-5-hack3-ld24
==5004== malloc/free: in use at exit: 5,676 bytes in 23 blocks.
==5004== malloc/free: 31 allocs, 8 frees, 15,626 bytes allocated.
==5004==
==5004== searching for pointers to 23 not-freed blocks.
==5004== checked 89,684 bytes.
==5004==
==5004== LEAK SUMMARY:
==5004== definitely lost: 0 bytes in 0 blocks.
==5004== possibly lost: 744 bytes in 3 blocks.
==5004== still reachable: 4,932 bytes in 20 blocks.
==5004== suppressed: 0 bytes in 0 blocks.
==5004== Reachable blocks (those to which a pointer was found) are not shown.
==5004== To see them, rerun with: --show-reachable=yes
--5004-- memcheck: sanity checks: 0 cheap, 1 expensive
--5004-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--5004-- memcheck: auxmaps: 0 searches, 0 comparisons
--5004-- memcheck: SMs: n_issued = 11 (176k, 0M)
--5004-- memcheck: SMs: n_deissued = 0 (0k, 0M)
--5004-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
--5004-- memcheck: SMs: max_undefined = 0 (0k, 0M)
--5004-- memcheck: SMs: max_defined = 29 (464k, 0M)
--5004-- memcheck: SMs: max_non_DSM = 11 (176k, 0M)
--5004-- memcheck: max sec V bit nodes: 1 (0k, 0M)
--5004-- memcheck: set_sec_vbits8 calls: 1 (new: 1, updates: 0)
--5004-- memcheck: max shadow mem size: 480k, 0M
--5004-- translate: fast SP updates identified: 3,211 ( 89.9%)
--5004-- translate: generic_known SP updates identified: 214 ( 5.9%)
--5004-- translate: generic_unknown SP updates identified: 144 ( 4.0%)
--5004-- tt/tc: 5,562 tt lookups requiring 5,665 probes
--5004-- tt/tc: 5,562 fast-cache updates, 3 flushes
--5004-- transtab: new 2,678 (57,324 -> 958,388; ratio 167:10) [0 scs]
--5004-- transtab: dumped 0 (0 -> ??)
--5004-- transtab: discarded 8 (169 -> ??)
--5004-- scheduler: 60,620 jumps (bb entries).
--5004-- scheduler: 0/3,114 major/minor sched events.
--5004-- sanity: 1 cheap, 1 expensive checks.
--5004-- exectx: 30,011 lists, 40 contexts (avg 0 per list)
--5004-- exectx: 58 searches, 18 full compares (310 per 1000)
--5004-- exectx: 0 cmp2, 51 cmp4, 0 cmpAll

Ce n'est peut-être pas un problème ? Je ne sais que dire.
On dirait qu'il a plus de "malloc" que de "free".

[DaZumba]

La glib maintient des variables globales privees qui ne sont pas desallouees explicitement: la glib laisse le systeme d'exploitation le faire pour elle. C'est ce que voit valgrind, mais ce n'est pas vraiment un probleme. Il est peut-etre possible de dire a valgrind de ne pas surveiller les allocations provenant de g_allocator_new().

[dj.motte]

Bonjour,

Voiçi le code source, et le résultat du debugger valgrind ( linux ).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

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 ?

[Fredy Kruger]

que ce n'est pas ta faute. J'ai obtenu le resultat similaire avec

main ( ...
{
gtk_int ( ... );
gtk_main ();
}

Je pense que c'est le problem de librarie Gtk+ ( ou valgrind est tres severe )

Fredy

[teuf13]

Pour faire du valgrind avec un gtk+ récent, il faut faire un
export G_SLICE=always-malloc
avant de lancer valgrind sinon il risque d'y avoir quelques faux positifs. Meme avec ca valgrind se plaint encore un peu ceci dit :p

[d'Oursse]

1) compile avec -g
2) ajoute a valgrind les options -v --leak-check=full. Tu peux aussi rajouter --leak-resolution=high et --show-reachable=yes (si tu as des commentaires de valgrind a propos d'adresses "reachable"

[dj.motte]

Salut,

A vrai dire je ne veux pas me servir de GTK mais seulement de la GLIB. Mais il n'y a pas de forum pour la GLIB.

Dans un but pédagogique je trouve que la GLIB du C propose des solutions au moins équivalentes à celles proposées par la STL du C++.

Mais si la documentation de la GLIB respecte le format linéaire de l'information, rien n'est vraiment appuyé par de simples exemples.

Pas de bol, en plus de cela je tombe sur le fameux

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
gboolean            g_file_get_contents                 (const gchar *filename,
                                                         gchar **contents,
                                                         gsize *length,
                                                         GError **error);

Sans exemple tout le monde va au casse pipe.

[teuf13]

Pour rappel...

Pour faire du valgrind avec un gtk+ récent, il faut faire un
export G_SLICE=always-malloc
avant de lancer valgrind sinon il risque d'y avoir quelques faux positifs. Meme avec ca valgrind se plaint encore un peu ceci dit :p

[dj.motte]

Salut,

Je pense que valgrind ça s'use quand on s'en sert...