Discussion :

[gwenhael]

Bonjour,
je tourne actuellement avec une Gentoo 2006.1, Gtk+-2.8.20-r1 glib-2.10.3 libX11-1.0.1-r1.
Si je fais une application simple du type :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
#include <gtk/gtk.h>
 
int main(int argc, char **argv) {
	gtk_init(&argc, &argv);
	GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);
	g_signal_connect(G_OBJECT(win), "destroy", G_CALLBACK(gtk_main_quit), NULL);  
	gtk_widget_show_all(win);
	gtk_main();
	return EXIT_SUCCESS;
}

les options de compils classiques... Enfin bref la compilation se passe sans problème ...
Là où ça va plus c'est quand je test avec valgrind ou mtrace.
Le log de valgrind fait environs 22572 lignes, énorme pour un truc qui ne fait rien ...
Visiblement le problème principal viens du display qui est créé par gtk_init() qui appel divers fonction de gdk et finalement XOpenDisplay(). au moment du gtk_main_quit il doit oublier de le libérer...
Quelqu'un subit il le même problème ou alors dans la même config que moi n'as pas justement cette fuite ?
Quelqu'un a t-il trouvé une solution ?
J'avoue ne plus comprendre parce qu'il y a peu, je n'avais absolument pas ça...

Gwenhaël

[granquet]

j'ai fait l'essai; (j'ai rajouté un #include <stdlib.h> pour le EXIT_SUCCESS)

Code :

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

1
2
3
 
ebola@gentoo ~/src $ mtrace gtk-test
No memory leaks.

et j'ai la meme chose que toi.

Code :

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

1
2
gentoo ~ # emerge -p gtk+
[ebuild   R   ] x11-libs/gtk+-2.8.20-r1

etrange !
--
ajout:

Code :

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

1
2
3
 
[ebuild   R   ] dev-libs/glib-2.10.3
[ebuild   R   ] x11-libs/libX11-1.0.3

tu peux mettre a jour la libX11. ça vaut le coup d'essayer. (meme si ca me parait tres simpliste comme solution)

[gwenhael]

Alors chose encore plus démente :
je rajoute #include <mcheck.h> et un appel à mtrace au début de main pour pouvoir avoir un fichier de trace pour mtrace
ensuite je compile et execute mon prog : le fichier est créé.
Je fais mtrace test trace.out j'ai des lignes et des lignes
je fais juste comme toi mtrace test pas de problème...
pour valgrind je fais :

Code :

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

1
2
 
valgrind -v --tool=memcheck --trace-children=yes --db-attach=no --log-file-exactly=error-valgrind.log --leak-check=yes  --leak-resolution=high --show-reachable=yes  ./test

[gwenhael]

J'avoue que je ne sais pas exactement depuis quand ca bug fin juin je n'avais pas ce problème ...
Par contre il me semble qu'entre temps gcc et glibc ont été mis à jour.
Pourrait-il y avoir un rapport de causes à effet ? Est-il possible que la glibc ou gcc soient en causes ?

[granquet]

bon, je crois que j'ai la meme chose que toi (en fait c'est la premiere fois que j'utilise mtrace, donc j'ai un peu de mal avec son fonctionement)

on commence par set la variable d'environement et on lance notre prog:

Code :

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

ebola@gentoo ~/src $ MALLOC_TRACE=errlog ./gtk-test

on lance notre l'utilitaire mtrace histore d'avoir un truc "human readable"

Code :

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

ebola@gentoo ~/src $ mtrace ./gtk-test errlog

et la j'ai 3067 lignes. (wc -l a l'appuis)

[gwenhael]

Ca me rassure ... Dans un sens, en même temps maintenant faut arriver à trouver pkoi ... Et comment éviter ...
Par contre si tu veux perdre les quelques dents qui te restent et faire la symétrie pour le pauchage des yeux lance valgrind comme j'avais noté tout à l'heure ... (22572 lignes environs, 1.6M de log) pour une pauvre fenêtre

[granquet]

je suis en train de me casser les dents la dessus ...
en fouillant un peu j'ai trouvé:

Les versions récentes de la bibliothèque C de Linux (libc postérieures à 5.4.23) et la bibliothèque GNU libc 2.x incluent une implémentation de malloc() dont on peut configurer le comportement à l'aide de variables d'environnement.
[...]
Si la variable MALLOC_CHECK_ vaut zéro, toutes les corruptions du tas détectées sont ignorées silencieusement; Si elle vaut 1 un message de diagnostique est affiché sur stderr. Si cette variable vaut 2, la fonction abort() est appelée immédiatement. Ce comportement est particulièrement utile car un crash pourrait sinon se produire ultérieurement, et serait très difficile à diagnostiquer.

lui ne donne aucun message.

--edit--
bon en fait ça nous sert a rien, y detecte pas les fuites memoires.
j'ai rien dis

[gwenhael]

As tu regardé les logs de valgrind, ils sont relativement clair et donne une idée de l'endroit où la mémoire est allouée.
J'ai bien essayé de fermer à la main le display mais ca fait tout planter ...

[granquet]

avant que ce topic ne tombe completement aux oubliettes:

http://www.gtk.org/faq/#AEN703

j'aimerais bien savoir ce qu'ils appellent des outils corrects de profiling?

[gwenhael]

C'est une très bonne question,
valgrind est deja pas mal pour tout ce qui est mémoire...(T'as essayé ?) Après tu en as tout un paquet ...
Enfin dans le cas présent faut juste un truc permettant de savoir où les alloc sont faites, et ainsi voir comment les supprimer...
Ce qui m'étonne terriblement c que je n'ai trouvé aucuns post sur des forums, mailing, etc... Ni aucuns rapports de bugs... Comme si on était les seuls ...

[granquet]

j'ai bien essayé valgrind ... j'ai 25,001 lignes dans le fichier de logs ... avec quasiment une fuite par fonction de la glibc ou de gtk.

ça m'etonnerais que la glibc (et//ou gtk+) soit si mal codé.

ce serait bien que quelqu'un sur une autre distribution puisse confirmer qu'il as les memes choses .

j'ai pas pu installer memprof -compile pas en x86_64- qui (deja il est en GTK) as l'air de pas detect de fuite memoires sur les progs GTK/Glibc.

[gwenhael]

en fait d'après mes logs ca ne viens pas de la glibc mais en fait il affiche l'arborescence des appels ou une alloc de mémoire a était réalisée sans qu'a la fin du programme la mémoire soit libérée.
si j'ai bien compris visiblement lors du gtk_main_quit(), le display n'est pas libérée, enfin c'est visiblement pas la seule mais déjà ça fait pas mal de ligne ...

[gwenhael]

Salut,
J'ai envoyé un mail sur une mailling de gtk, une personne m'a dit que sous fedora le même code ne posait pas de problèmes...
Par contre j'ai pas ni la version de fedora ni des librairies...
Je me demande si c'est pas un problème spécifique à gentoo ... Ou aux USE de compil...

[granquet]

j'ai crut avoir une idée ... mais non, j'ai pensé que ça pouvais venir des nptl (vut que sur fedora ils ne doivent pas encore etre en nptl) mais valgrind se debrouille tres bien avec sur des programmes qui n'utilisent pas GTK.


je suis en x86_64, un copain en x86 sous gentoo as la meme chose.
je vais ouvrir un thread sur le forum gentoo ... ptetre que quelqu'un de plus competent que moi sauras repondre

---
sinon j'ai trouvé ceci: http://mail.gnome.org/archives/gtk-d.../msg00229.html

interressant !

[gwenhael]

En fait après coup j'ai l'impression que le mec n'as pas utilisé les bons paramètres pour valgrind et c legerement loupé... Donc je sais même si en fait il a pas le même problème.
pour ce qui est du post que t'as trouvé, c'que je n'arrive pas à comprendre c'est pourquoi dans le passé j'avais pas de problème et maintenant si... Sans parler que mtrace affiche quelques paquets de lignes...

[nathiara]

Salut, j'ai le mêm problème sous ubuntu, j'utilise la librairie gtk-2.0, avez-vous une solutions?
merci