Discussion :

[flamme34]

Bonjour a tous,

voila j'ai coder un programme en c++ qui me permet de communiquer avec une machine. Or lorsque je laisse le programme tourner relativement longtemps (arrive surtout lorsque le programme tourne toute une nuit ) j'obtiens une exception "out of memory".

Ayant fait une recherche Google ( je pr�cise pour ceux qui me mettrais que google est mon ami JE SAIS ! ) : Je sais qu'une exception de "out of memory" provient du saturation de la m�moire.

Etant sous un compilateur 32 bits je sais que je peut aller jusqu�� 2.5Go sans probl�me normalement. Or l� le probl�me c'est que lorsque j'observe avec le gestionnaire de tache la m�moire utilis�e par mon processus elle ne d�passe pas les 20 M�ga.

De quoi d'autre peut provenir cette erreur de out of memory ??????

J'ai v�rifi� tout mes "new" pour �tre s�r qu'un "delete" y soit associ�.

[Davidbrcz]

J'ai v�rifi� tout mes "new" pour �tre s�r qu'un "delete" y soit associ�.

Apparemment pas
Mais en utilisant les conteneurs de la STL et les pointeurs intelligents, tu ne devrais quasiment avoir plus de new/delete a �crire

Essaye de voir si tu passer ton programme sous un analyseur tel valgrind ou Rational Purify

[LinuxUser]

Un petit coup de valgrind:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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

Par contre, je connaissais pas Rational Purify, je vais tester �a pour voir.
Rien que le nom en impose

[jblecanard]

Par contre, je connaissais pas Rational Purify, je vais tester �a pour voir.
Rien que le nom en impose

Rational Purify est payant, si tu n'en disposes pas et que tu ne peux pas utiliser valgrind parce que ton appli ne tourne pas sous linux, tu peux essayer drmemory.

[dragonjoker59]

Sous Windows, avec Visual Studio il y a aussi Visual Leak Detector.
Mais en tout cas il faut effectivement se m�fier du gestionnaire des t�ches par rapport � l'occupation m�moire de ton appli.

[Astraya]

En debug, tu peux surcharger tes new et delete. A Chaque new, tu rajoutes l'adresse allou� dans un map avec la line et le nom de fichier en objet de la map et l'adresse en cl�. En delete, tu supprimes cette entr�e.
A la destruction de ta map tu assert si il y a encore des entr�es dans la map, et tu sauras gr�ce � la ligne et le nom de fichier ou est ton new qui d�conne.

[Bousk]

Bonsoir,

Ayant fait une recherche Google ( je pr�cise pour ceux qui me mettrais que google est mon ami JE SAIS ! ) : Je sais qu'une exception de "out of memory" provient du saturation de la m�moire.

Etant sous un compilateur 32 bits je sais que je peut aller jusqu�� 2.5Go sans probl�me normalement. Or l� le probl�me c'est que lorsque j'observe avec le gestionnaire de tache la m�moire utilis�e par mon processus elle ne d�passe pas les 20 M�ga.

� moins que ton application soit la seule � �tre ex�cut�e sur la machine, toutes partagent la m�me ram et peuvent donc la saturer.

[flamme34]

d�sol� du temps de r�ponse mais j'ai �t� pas mal occup�e ces dernier temps.

� moins que ton application soit la seule � �tre ex�cut�e sur la machine, toutes partagent la m�me ram et peuvent donc la saturer.

Je n'est que cette appli qui tourne a l'exception des programmes habituels (logiciel de gestion de carte graphique, anti virus, etc )

Essaye de voir si tu passer ton programme sous un analyseur tel valgrind ou Rational Purify

En toute logique si il devais y avoir une fuite m�moire je devrais la voir dans la m�moire utilis� gr�ce au gestionnaire de tache de Windows?non?

[darkman19320]

Salut,

Je suis pas s�r que le gestionnaire des t�ches de Windows te soit d'un grand secours si ton exception "out of memory" n'est lanc� qu'au bout d'une nuit...

Cherche plut�t du c�t� de valgrind comme te le conseil LinuxUser ou si tu utilises visual studio 2012, tu peux regarder ceci (je n'ai pas test� cette solution).

[white_tentacle]

Le gestionnaire des t�ches de windows a une mani�re bien � lui d�afficher la m�moire utilis�e.

Notamment, il y a plusieurs colonnes :
memory size
vm size

et encore un troisi�me que je n�ai plus en t�te.

Dans ton cas, je pense qu�il faut regarder la VM size, elle doit �tre beaucoup plus importante que tes 20 Mo.

Autre chose : pour observer les memory leaks, un outil tr�s pratique est le perfmon. Tu rajoutes un compteur sur les � private bytes � de ton process : s�ils augmentent sans jamais redescendre, il y a tr�s vraisemblablement une fuite m�moire.