Gtkmm et fuite de mémoire?

tiky · Le 25/08/2008, à 21:55

Bonsoir, je viens de lancer valgrind sur un projet en Gtkmm / C++ et le rapport est plus qu'inquiétant puisqu'il trouve des centaines de fuites de mémoires. Vous me direz que ça doit être de ma faute, pourtant j'ai bien fait attention. Je fais une recherche sur Internet et je trouve d'autres personnes dans la même situation, cela ne toucherai que Gentoo apparemment. Je code un mini programme en Gtkmm pour voir:

#include <gtkmm.h>

int main( int argc, char ** argv )
{
        Gtk::Main kit( argc, argv );
        Gtk::Window win;
        Gtk::Main::run( win );
        return 0;
}

Aucune allocation mémoire faite par moi dans ce code. Je compile avec cette commande:

g++ -o code code.c -Wall -g `pkg-config gtkmm-2.4 --cflags --libs`

Et je lance valgrind avec cette commande:

valgrind --leak-check=yes ./code

Et j'obtiens le résultat suivant:

==5320== LEAK SUMMARY:
==5320==    definitely lost: 2,084 bytes in 2 blocks.
==5320==    indirectly lost: 120 bytes in 10 blocks.
==5320==      possibly lost: 63,728 bytes in 58 blocks.
==5320==    still reachable: 270,033 bytes in 4,928 blocks.
==5320==         suppressed: 0 bytes in 0 blocks.

Pas cool , vous avez la même chose chez vous?
Précision:
J'ai gtkmm-2.12.7, gtk+-2.12.11.

Dernière modification par tiky (Le 25/08/2008, à 21:59)

rniamo · Le 25/08/2008, à 22:33

j'ai un truc kif kif sur un programme perso.

tiky · Le 25/08/2008, à 22:47

J'obtiens ça pour mon programme, je pense pas que ce soit mon code mais un problème au niveau de gtkmm:

==5413== LEAK SUMMARY:
==5413==    definitely lost: 12,836 bytes in 40 blocks.
==5413==    indirectly lost: 23,444 bytes in 1,161 blocks.
==5413==      possibly lost: 120,872 bytes in 119 blocks.
==5413==    still reachable: 5,312,014 bytes in 14,375 blocks.
==5413==         suppressed: 0 bytes in 0 blocks.

rniamo · Le 25/08/2008, à 23:06

ou valgrind, il faudrait tester sur un autre programme, je vais voir

rniamo · Le 25/08/2008, à 23:14

idem avec du gtk+

tiky · Le 25/08/2008, à 23:17

Quand je lance un valgrind sur nautilus c'est pas mal aussi... ça vient peut-être de valgrind alors.

tiky · Le 25/08/2008, à 23:22

Bon ça doit venir de valgrind, il y a bien mtrace mais il détecte que les malloc, donc pas les pointeurs intelligents, et les new/delete je suppose.

tiky · Le 25/08/2008, à 23:52

Je viens de trouver ça: http://mail.gnome.org/archives/gtk-devel-list/2004-April/msg00229.html

rniamo · Le 26/08/2008, à 08:11

en c ok mais en c++ c'est bizarre ...

rniamo · Le 26/08/2008, à 08:12

en c ok mais en c++ c'est bizarre ...

tiky · Le 26/08/2008, à 11:47

Pourquoi en C c'est normal? une bonne bibliothèque ne devrait pas générer de fuite de mémoire lorsqu'elle est bien utilisée.

rniamo · Le 26/08/2008, à 21:46

oui mais qu'en c tu doivent appelé une fonction pour libérer la mémoire ça ne me choque pas mais en c++ ça devrait être dans un destructeur ... enfin je pense

Link31 · Le 26/08/2008, à 22:36

valgrind --leak-check=full --show-reachable=yes  ./code

On devrait y voir plus clair avec ça.

Si il s'affiche vraiment trop de texte, enlève le --show-reachable=yes.

tiky · Le 26/08/2008, à 22:50

Déjà fait, et oui il y en a des lignes et des lignes...

nicolas66 · Le 27/08/2008, à 02:56

Il y a quelques mois, j'avais été aussi très surpris de voir les nombreuses fuites mémoires présentes dans la SDL.

Une autre fois, lors d'un stage en angleterre, j'ai fait la connaissance d'un gars qui bossait sur un projet européen de réalité virtuelle. Sur le coup, j'ai halluciné sur la liste de warnings qu'il avait tandis que de mon côté, je bossais sur le même outil que lui (SDK de UT2003) et je m'efforçais toujours de supprimer ces warnings. Il me répondait qu'il n'avait pas le temps de gérer ce genre de trucs et qu'il avait des impératifs.

Pour revenir au problème initial, je pense que les développeurs sont au courant de ces fuites mémoires et doivent considérer qu'elles ne sont pas "critiques". Si tu penses que ce sont des fuites mémoires "critiques", tu peux toujours envoyer un bug report sur le site de gtkmm. Tu nous donneras leur réponse

Dernière modification par nicolas66 (Le 27/08/2008, à 02:58)

Link31 · Le 27/08/2008, à 21:41

tiky a écrit :

Déjà fait, et oui il y en a des lignes et des lignes...

Je sais bien qu'il y a des lignes...

Toi, quand tu lances une commande, tu te contentes de regarder si ça "sort des lignes" ou pas ?

tiky · Le 27/08/2008, à 22:55

Non bien sûr, les voilà les lignes pour la commande:

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes

Nb: je l'ai lancé sur mon projet, il y a plus de lignes parce que j'utilise beaucoup plus de classes Gtk que dans l'exemple simple au début de ce topic, mais j'ai peut-être fait une erreur dans mon code bien évidemment
L'ingrat résultat:
http://pastebin.com/m3d5063f3

( Je ne pouvais pas le copier directement dans le message, le forum me l'interdit ).

Dernière modification par tiky (Le 27/08/2008, à 22:55)

Link31 · Le 27/08/2008, à 23:21

Bon, j'ai jeté un (très) rapide coup d'oeil, et on dirait bien que ton code est hors de cause, du moins directement.

Seulement, ça paraît surprenant que tant de bibliothèques différentes présentent des "fuites de mémoire". À mon avis, tu ne termines pas ton programme correctement. Il doit exister une fonction qu'il faut appeler explicitement pour faire le ménage, malgré le fait que ça devrait être fait dans les destructeurs.
Il ne faut pas oublier que GTK est une bibliothèque C à la base, langage qui ne permet pas le RAII et avec lequel on tolère bien souvent les fuites de mémoire lors de la fermeture d'un programme.

tiky · Le 28/08/2008, à 02:34

Voilà le helloworld gtkmm: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-helloworld.html

Mon code appelle les mêmes fonctions.. par contre je ne définie pas destructeur dans mes classes dérivant d'une classe Gtk, ça peut venir de là? Je pense pas mais sait-on jamais?

robrob · Le 28/08/2008, à 07:44

Un hello world similaire en wxwidget (qui utilise aussi gtk dans sa version nunux):

#include <wx/wxprec.h>
#ifndef WX_PRECOMP
#include <wx/wx.h>
#endif // WX_PRECOMP

#include <iostream>

class hello_frame : public wxFrame
{
	public: hello_frame();
	
	private: void hello_click(wxCommandEvent& event);
	
	DECLARE_EVENT_TABLE()	
};

class hello : public wxApp
{
	public: virtual bool OnInit();
};

//------------------------------------------------------------------------------- 
// Classe hello

IMPLEMENT_APP(hello)

bool hello::OnInit()
{  			
	hello_frame *frame = new hello_frame();	
	frame->Show(TRUE);
	SetTopWindow(frame);
	
	return TRUE;
};

//------------------------------------------------------------------------------- 
// Classe hello_frame

BEGIN_EVENT_TABLE(hello_frame, wxFrame)
	EVT_BUTTON(100,hello_frame::hello_click)
END_EVENT_TABLE()

hello_frame::hello_frame()	
	: wxFrame(NULL, wxID_ANY, wxT("Hello"))
{
	new wxButton(this,100,wxT("Hello World"));
};

void hello_frame::hello_click(wxCommandEvent& /*event*/)
{
	std::cout << "Hello World!" << std::endl;
}

Ce code génère tout autant d'erreur (148 avec la ligne de commande de tiky) que son équivalent en gtkmm.

Conclusion, soit:
- valgrind génère de fausses erreurs (ça peut lui arriver)
- gtk a des petites incontinences

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 25/08/2008, à 21:55

Gtkmm et fuite de mémoire?

#2 Le 25/08/2008, à 22:33

Re : Gtkmm et fuite de mémoire?

#3 Le 25/08/2008, à 22:47

Re : Gtkmm et fuite de mémoire?

#4 Le 25/08/2008, à 23:06

Re : Gtkmm et fuite de mémoire?

#5 Le 25/08/2008, à 23:14

Re : Gtkmm et fuite de mémoire?

#6 Le 25/08/2008, à 23:17

Re : Gtkmm et fuite de mémoire?

#7 Le 25/08/2008, à 23:22

Re : Gtkmm et fuite de mémoire?

#8 Le 25/08/2008, à 23:52

Re : Gtkmm et fuite de mémoire?

#9 Le 26/08/2008, à 08:11

Re : Gtkmm et fuite de mémoire?

#10 Le 26/08/2008, à 08:12

Re : Gtkmm et fuite de mémoire?

#11 Le 26/08/2008, à 11:47

Re : Gtkmm et fuite de mémoire?

#12 Le 26/08/2008, à 21:46

Re : Gtkmm et fuite de mémoire?

#13 Le 26/08/2008, à 22:36

Re : Gtkmm et fuite de mémoire?

#14 Le 26/08/2008, à 22:50

Re : Gtkmm et fuite de mémoire?

#15 Le 27/08/2008, à 02:56

Re : Gtkmm et fuite de mémoire?

#16 Le 27/08/2008, à 21:41

Re : Gtkmm et fuite de mémoire?

#17 Le 27/08/2008, à 22:55

Re : Gtkmm et fuite de mémoire?

#18 Le 27/08/2008, à 23:21

Re : Gtkmm et fuite de mémoire?

#19 Le 28/08/2008, à 02:34

Re : Gtkmm et fuite de mémoire?

#20 Le 28/08/2008, à 07:44

Re : Gtkmm et fuite de mémoire?

Pied de page des forums