Discussion :

[Fraggy]

Bonjour à tous,
j'ai une application qui ne fait pas de "new" en dehors de la période d'initialisation. A priori vu que je ne manipule que des données déjà existantes y a pas de raison que ma mémoire soit grignotée petit à petit.

j'ai déjà vérifié, ce n'est pas un de mes vecteurs qui augmentent de taille.

qu'est ce qui peut provoquer une fuite de mémoire ?
je me souviens plus comment on fait pour connaître la mémoire alloué par le programme quand on a que la STL et posix a sa disposition...

Vincent

[Florian Goo]

Bonjour,

Peux-tu nous expliquer plus en détail ce que fait ton programme ?
Une augmentation de la mémoire allouée ne signifie pas forcément une fuite mémoire. Cela peut provenir d'un buffer qui ne se vide pas, d'un empilage de données qui ne sont pas dépilées, …

[white_tentacle]

Tu n'appellerais pas des fonctions qui initialisent des handle sur des objets, et que tu oublies de libérer ?

[Fraggy]

Bonjour,
Peux-tu nous expliquer plus en détail ce que fait ton programme ?

En gros c'est un moteur de physique, j'ai un monde virtuel dans lequel je peux rajouter des objets 3D, le monde virtuel detecte les collisions possible, les résouds etc...
J'ai une boucle qui se lance au début de chaque frame dans l'ordre :
- tri des objets (pour baisser le nb de paire)
- detection des pairs
- résolution des pairs en collision

Une augmentation de la mémoire allouée ne signifie pas forcément une fuite mémoire. Cela peut provenir d'un buffer qui ne se vide pas, d'un empilage de données qui ne sont pas dépilées, …

c'est quoi un empilage de données ?

Tu n'appellerais pas des fonctions qui initialisent des handle sur des objets, et que tu oublies de libérer ?

je n'utilise pas de handle, juste des pointeurs et des reférences c'est tout.
dis m'en plus sur les handles, je connais pas trop... je suis un vieu je connais pas la programmation windows :p

Vincent, je ne fait que du C++ Orienté Objet dans cette bibliothèque, avec la STL et un peu de POSIX (mais ca bug même sans creer de thread)... comprend pas. Qui peut me rappeler comment on fait pour avoir la quantité de menoire pris par le programme en C/C++ non windows ?

[Florian Goo]

Qui peut me rappeler comment on fait pour avoir la quantité de menoire pris par le programme en C/C++ non windows ?

Non Windows ? C'est à dire que tu es sous Linux ?
Sous Unix en général, il y a la commande top pour ça (avec l'option -p pour avoir un processus particulier). Mais je dois dire que je ne suis pas un spécialiste de la ligne de commande.

Par empilage, je faisais référence à la pile système : http://fr.wikipedia.org/wiki/Allocation_de_mémoire

Enfin, un handle, c'est un identifiant vers un objet alloué dynamiquement. C'est surtout utilisé en C. En C++, on subit ce genre de vieilleries quand on travaille directement avec l'API système (comme l'API Windows).

Je dois reconnaitre que je ne sais pas quoi dire pour l'instant…
Si j'étais à ta place, je réduirais mon code au fur et à mesure jusqu'à obtenir un exemple minimal, afin d'isoler le problème.

[wakan]

Bonjour,

c'est quoi un empilage de données ?

Vous devriez faire quelques recherches sur les structures de données. C'est très instructif et passionnant. Pour débuter je te conseil ceci : Structure de données.

je n'utilise pas de handle, juste des pointeurs et des références c'est tout.

Je penses que c'est les pointeurs qui font des fuites de mémoire il faudrait que vous adoptiez une stratégie de gestion de mémoire efficace. Cf voir Ceci.

dis m'en plus sur les handles, je connais pas trop...

Voilà je trouves que cette article sur Wikipédia explique cela assez bien ici.

Qui peut me rappeler comment on fait pour avoir la quantité de menoire pris par le programme en C/C++ non windows ?

Désolé je n'en c'est rien, il faudra attendre quelqu'un qui est plus spécialisé que moi sur ce sujet.

A bientôt

[Fraggy]

Non Windows ? C'est à dire que tu es sous Linux ?

Je suis sous windows mais je fais du c++ standard, j'ai pas acces au API Windows...

Par empilage, je faisais référence à la pile système

a priori la pile se vide quand on quitte la fonction ou elle est utilisée.. je dois vérifier un truc quand même.

Je dois reconnaitre que je ne sais pas quoi dire pour l'instant… Si j'étais à ta place, je réduirais mon code au fur et à mesure jusqu'à obtenir un exemple minimal, afin d'isoler le problème.

C'est ce que je fais pour le moment ...

[Fraggy]

Pour débuter je te conseil ceci : Structure de données.

heu, je crois pas qu'on parle de la même chose la.

Je penses que c'est les pointeurs qui font des fuites de mémoire il faudrait que vous adoptiez une stratégie de gestion de mémoire efficace. Cf voir Ceci.

j'ai préciser dans mon post initial que je ne faisais de new qu'au debut du programme et qu'il n'y a aucun autre new par la suite. donc en terme de fuite de mémoire ça ne pouvait pas être ca.

Voilà je trouves que cette article sur Wikipédia explique cela assez bien ici.

pareil... on parle pas de handle de fichier mais de handle de programme...

[ram-0000]

j'ai préciser dans mon post initial que je ne faisais de new qu'au debut du programme et qu'il n'y a aucun autre new par la suite. donc en terme de fuite de mémoire ça ne pouvait pas être ca.

Toi tu ne fait pas de new mais peut être qu'insidieusement, il y a des new qui sont faits ailleurs dans le code (un vector ou une list qui grandit).

Ce que tu peux faire si tu maitrise le code de l'application c'est de surcharger le new et le delete global et ainsi de tracer les appels avec les taille allouées. Cela ne marche que pour new et delete, pour les malloc et free, faudra trouver autre chose. Je ne sais pas si Valgrind ne sait pas faire de la détection de fuite mémoire.

Dans le livre Penser en C++ traduit par l'équipe, il y a un exemple pour surcharger le new et le delete global (chapitre 13.5.1)

[Fraggy]

Toi tu ne fait pas de new mais peut être qu'insidieusement, il y a des new qui sont faits ailleurs dans le code (un vector ou une list qui grandit).

J'ai vérifiés tous mes vecteurs, aucun ne grandit sans raison. un vecteur ne fait pas de new sans rien dire par contre il alloue de la mémoire que le vecteur conserve tant qu'il existe. et j'ai déjà vérifier mes vecteurs

Ce que tu peux faire si tu maitrise le code de l'application c'est de surcharger le new et le delete global...

c'est pas les new

Je ne sais pas si Valgrind ne sait pas faire de la détection de fuite mémoire.

Je vais regarder valgrind...pour voir

[Alp]

Pour plus de "sécurité" sur l'allocation dynamique, essaye les pointeurs intelligents. Ce sera standard dans la prochaine version de C++ via les Smart Pointers de Boost, donc Loïc parle dans son article. Ca t'assurera l'absence de problèmes de ce côté là et te permettra de trouver la vraie source.

[nikko34]

ben si toi même qui a fait l'appli tu sais pas quelle partie serait susceptible de faire monter la mémoire, on va pas pouvoir t'aider beaucoup plus

sinon oui si en supprimant certaines parties/faire du debug tu n'arrives à rien voir, utilise quelque chose comme valgrind

[Fraggy]

ben si toi même qui a fait l'appli tu sais pas quelle partie serait susceptible de faire monter la mémoire, on va pas pouvoir t'aider beaucoup plus

Oui je sais

en ce moment j'utilise le gestionnaire de mémoire de windows il me dis dans l'onglet processus combien mon appli prend de mémoire... et en faisant du pas a pas ca me permet de voir ce qui pose pb.

sauf que ce gestionnaire ne me donne qu'une valeur arrondie... je trouve ce soir ou je me pends a ma souris.
->je télécharge process explorer :p (mais finalement ca me donne pas la taille memoire a l'octet pret....)

[JolyLoic]

Une technique qui peut aider :
Met un compteur d'instance avec trace dans les principaux objets de ton application, et regarde si le nombre d'un de ces objets augmente insidieusement. Ça peut déjà aider à cibler le problème.

Par exemple, un truc genre :

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
23
24
25
26
27
28
29
30
31
32
template <class T> struct InstanceCounter
{
	InstanceCounter(std::string const &name) : myName(name)
	{
		++count;
		display("(++)");
	}
	~InstanceCounter() 
	{
		--count;
		display("(--)");
	}
	void display(std::string const &reason)
	{
		cout << "Number of " << myName << ": " << count << reason << endl
	}
	static int count;
	std::string myName;
};
 
class MaClasseATester 
#ifndef NDEBUG
    : InstanceCounter<MaClasseATester>
#endif
{
    MaClasseATester() 
#ifndef NDEBUG
         : InstanceCounter<MaClasseATester> ("MaClasseATester (default cstr)")
#endif
    {}
  // ...
};

[Fraggy]

Une technique qui peut aider :
Met un compteur d'instance avec trace dans les principaux objets de ton application, et regarde si le nombre d'un de ces objets augmente insidieusement. Ça peut déjà aider à cibler le problème.

Merci, ça peut servir carrément, mais je rappelle que ce n'est pas un probleme de new : j'ais crée TOUS mes objets au départ, je les stocke dans un vecteur et quand j'en ai besoin, au lieu de faire un new je vais piocher dedans et au lieu de faire un delete je les replace dans le vecteur.
->pas de new dans mon programme, donc le compteur d'instance ne m'aidera pas :p

j'ai résolu le pb, j'avais des informations de debug sous la forme de string concaténé (je sais c'est mal) plus le temps passait plus mes objets stockaient des informations dans ce string. En virant ce string de debug ca marche mieux.

merci de votre réactivité, merci a ceux qui m'ont aidé :p ca fait du bien de ne pas se sentir seul

Vincent, j'ai plus de fuite, ça monte ça descend, ça doit être due a des taches solaires.

[JolyLoic]

Merci, ça peut servir carrément, mais je rappelle que ce n'est pas un probleme de new : j'ais crée TOUS mes objets au départ

Il y a une différence entre ne pas avoir de new, et ne pas créer d'objets... Mais puisque tu as résolu ton problème, c'est que c'était autre chose...

[loufoque]

Valgrind est le meilleur outil pour ça.
Il te permettra de tout vérifier, erreurs mémoires, fuites, etc. dans l'intégralité du programme.

[Fraggy]

Il y a une différence entre ne pas avoir de new, et ne pas créer d'objets...

Comment on fait (sans faire de new ou de malloc) pour créer un objet qui restera en mémoire même si on quitte la fonction qui vient de le créer ?

J'avais pensé à un vecteur qui grandissaient (alors qu'il ne devait pas) et finalement c'était un string (j'avais des milliers de spheres dans mon vecteur et chaque sphere dispose d'un string de debug qui enregistrait tout ce qui se passaient scrupuleusement...)

Vincent

[JolyLoic]

Comment on fait (sans faire de new ou de malloc) pour créer un objet qui restera en mémoire même si on quitte la fonction qui vient de le créer ?

J'avais pensé à un vecteur qui grandissaient

Justement, on fait avec un tel vecteur, dans lequel on colle l'objet qu'on vient de créer.