Discussion :

[troumad]

Bon, j'ai l'impression que cette recherche demande vraiment beaucoup de temps pour un résultat nul.
Il vient de me relever cette fonction : https://developer.gnome.org/gtk3/sta...r-get-children . Je me suis dit : je libère la place à la fin. Bilan : un plantage sur le g_free.

Je ne nie pas qu'il puisse y avoir des fuites de mémoire dans mon programme, mais avant que je me lance à leur recherche, il faudra que je vois que c'est gênant !

[gerald3d]

Salut.

Bon comme je vois que tu n'es pas très inspiré par la recherche des fuites, je l'ai fait pour toi .

Commençons ici :

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
void lire_sorts(char * ici)
{
 char * chemin;

 ici=chemin_exe();

 chemin=g_build_path (G_DIR_SEPARATOR_S,ici,"fichiers","sorts","sort-clerc.ods",NULL);
 sortileges=lire_struct_sort(chemin,CLERC);
 if (sortileges==NULL)
 {
     printf("Surprise : le fichier %s a un problème\n",chemin);
 }
 free(chemin);

 chemin=g_build_path (G_DIR_SEPARATOR_S,ici,"fichiers","sorts","sort-mag.ods",NULL);
 sortileges_mag=lire_struct_sort(chemin,MAGICIEN);
 if (sortileges==NULL)
 {
     printf("Surprise : le fichier %s a un problème\n",chemin);
 }
 free(chemin);
}

chemin_exe(); renvoie un espace alloué. Il te faut le libérer par un g_free(ici);.
Pendant que j'y suis avec cette fonction si tu veux émettre des logs en console l'idéal est de le faire dans le canal dédié qui est stderr. Tu peux le faire en écrivant dedans directement fprintf(stderr, "Surprise : le fichier %s a un problème\n",chemin); ou bien en utilisant la fonction de la glib g_printerr("Surprise : le fichier %s a un problème\n",chemin);.

Dans la fonction void retourne_psi(struct_psi_c * psi_, char * fichier); tu utilises la fonction signed short * lire_caract(char ** ch);. Cette fonction utilise le retour de la fonction char ** feuille_lire_ligne(char * coordonnees,GMarkupDomNode * node) comme paramètre. Elle alloue dans le tas. À aucun moment tu récupères le pointeur retourné pour te permettre de libérer. Au vu de ton code je pense que la donnée, une fois utilisée n'est plus nécessaire. Je peux me tromper bien sûr.

Pour le reste il semblerait que ce soit du fait de Gtk+.

Bien entendu il faut se rappeler que ces warnings sont apparus juste en lançant l'application et en la quittant dans la foulée. Si tu viens à utiliser plus en profondeur ton application tu verras apparaître sûrement d'autres coquilles.

[troumad]

J'avoue finir de corriger 240 copies... J'ai fait autre chose cette semaine et demain, je ne pense pas programmer non plus.

Le "ici=chemin_exe();" me surprend plus qu'autre chose. Normalement, le chemin est récupéré dans les paramètres d'appel. Il faudra que je vérifie. Je pense que le programme devrait tourner sans cet appel. Je viens de le supprimer et je testerai une autre fois.

La fonction retourne_psi, comme les autres du fichier sorts.c remplit des tableaux qui peuvent être utiles tant que le programme tourne. Ce sont des tableaux globaux à ce fichier que je renvoie aux autres fichiers du programme grâce aux fonctions "donne_" du début du fichier. Ces tableaux se retrouvent désalloué automatiquement quand le programme se ferme.

[gerald3d]

La fonction retourne_psi, comme les autres du fichier sorts.c remplit des tableaux qui peuvent être utiles tant que le programme tourne. Ce sont des tableaux globaux à ce fichier que je renvoie aux autres fichiers du programme grâce aux fonctions "donne_" du début du fichier. Ces tableaux se retrouvent désalloué automatiquement quand le programme se ferme.

Des tableaux globaux...on touche à la fameuse question : global or not global ? Le déboguage se complexifie lorsqu'il existe des variables globales. De mon point de vue, c'est une pratique à éviter au maximum (je dirais même à proscrire, mais là je suis un peu extrémiste ). Enfin, je le répète, ce n'est que mon point de vue. .

Ceci dit, si tu es sûr de ton contrôle, oublions la remarque.

Bonnes corrections.

[troumad]

j'avais discuté de ces tableaux sur le forum C. Je les considère comme constants. C'est à dire qu'ils sont remplis au démarrage à partir des fichiers de configuration et après, ils ne bougent plus. C'est pour ça que l'appel se fait à partir des autres fichiers comme si c'était des constantes. Tu peux voir la définition de ces "constantes" à partir de la ligne 618 du fichier "include.h" par exemple.

nb : mes corrections sont finies

edit : en effet, ici=chemin_exe(); était inutile. C'est le reste d'une ancienne version.

Une remarque pour l'affichage des erreurs :

Pendant que j'y suis avec cette fonction si tu veux émettre des logs en console l'idéal est de le faire dans le canal dédié qui est stderr. Tu peux le faire en écrivant dedans directement fprintf(stderr, "Surprise : le fichier %s a un problème\n",chemin); ou bien en utilisant la fonction de la glib g_printerr("Surprise : le fichier %s a un problème\n",chemin);.

Le premier cas n'est pas possible car il n'y a à priori pas obligatoirement une erreur générée.
Le second pourrait être envisageable, mais comme tous les printf sont des affichages d'erreur, il faudrait tous les changer.

[troumad]

Dans le genre fuite de mémoire, il y a les glist : les effacer ou non ?
https://developer.gnome.org/gtk3/sta...r-get-children : ne dit rien
https://developer.gnome.org/gtk3/sta...t-list-classes : dit qu'il faut l'effacer

[gerald3d]

Dans le genre fuite de mémoire, il y a les glist : les effacer ou non ?
https://developer.gnome.org/gtk3/sta...r-get-children : ne dit rien
https://developer.gnome.org/gtk3/sta...t-list-classes : dit qu'il faut l'effacer

Pour moi cela me semble clair :

• GList * gtk_container_get_children (GtkContainer *container); : Returns a newly-allocated list of the container’s non-internal children. Donc à libérer une fois son utilisation terminée,
• GList * gtk_style_context_list_classes (GtkStyleContext *context); : The contents of the list are owned by GTK+, but you must free the list itself with g_list_free() when you are done with it. Même chose ici mais dit différemment.

[troumad]

C'est la différence qui me gène. En effet, selon moi, il fallait libérer les deux places, mais c'était tellement bien dit la seconde fois, que je ne voyais pas pourquoi ce n'était pas aussi clair la seconde.