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