Discussion :

[Ange_blond]

Bonjour,

Je sais que le sujet a déjà été traité, mais j'ai des soucis de cohérence dans mes résultats depuis ce matin.

En gros, je traque les fuites mémoire. Pour celà, j'utilise le code suivant dans une méthode statique.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
    DWORD pid = GetCurrentProcessId();
    //size_type result;
    HANDLE hProcess;
    PROCESS_MEMORY_COUNTERS pmc;
    hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,false,pid);
    if (GetProcessMemoryInfo( hProcess, &pmc, sizeof(pmc)))
    {
WorkingSetSize:
        result = pmc.WorkingSetSize; // memoire utilisé par le code
    }
    CloseHandle( hProcess );

Pour tester mon procédé, j'ai d'abord fait un test simple :

* getProcMemory
* malloc(1000*sizeof(double))
* getProcMemory

La différence de mémoire mesurée (en octets donc) est originale : 4096 octets
Si j'alloue 10000 double, j'ai une mémoire mesurée de 81920 ... (pas vraiment 10 fois plus)

En debug, j'ai 4096 octets de différence rien qu'en fesant

* getProcMemory
* getProcMemory

mais rien en Release (0 octets) !!

Je commence a douter sérieusement de GetProcessMemoryInfo() ... ou alors je l'utilise mal...
Faut il necessairement un process séparé ?
Y a t il des restrictions ?

Comment mesurer précisément la mémoire utilisée par le processus courant par une autre méthode sinon ?

Merci de votre aide.

Ange_blond

[bacelar]

<MSDN>
WorkingSetSize
The current working set size, in bytes.
</MSDN>

Vous confondez la mémoire utilisée et WorkingSet.
Enfin, mémoire utilisée c'est un peu vague. Ca veut dire quoi utilisée ?
-réservée en mémoire virtuelle ?
-adossé à une page physique de mémoire ?
-page swapé sur disque ?
-etc..

Le WorkingSet n'est que la taille de l'ensemble des pages physiques de mémoire attribuée à ce process. C'est la mise en swap d'une partie du code ou des données où leur retour en mémoire qui influence le plus cette taille.

C'est normal que votre workingSet ne suive pas votre allocation mémoire à la lettre.
Un malloc peu utilisé de la mémoire déjà utilisé précédemment et déjà libéré par votre code mais non restitué à l'OS.
Une partie de l'allocation n'est qu'une réservation de la plage d'adresse virtuelle dans l'espace d'adressage du programme. La récupération de la page physique se fera sur un défaut de page.
etc...

Gros WorkingSet, problème de localité du code ou des données.
"Petit" WorkingSet, programme correctement optimisé.

[Ange_blond]

Bonjour,

D'abord merci de votre réponse.

Vous confondez la mémoire utilisée et WorkingSet.
Enfin, mémoire utilisée c'est un peu vague. Ca veut dire quoi utilisée ?
-réservée en mémoire virtuelle ?
-adossé à une page physique de mémoire ?
-page swapé sur disque ?
-etc..

A vrai dire j'en sais rien... Je cherche a connaitre la taille de mémoire allouée par le processus, pour pouvoir faire les différence avant/apres création d'un objet et traquer les fuites mémoire.
Je n'ai pas de meilleure idée pour faire ça...


Je ne connais rien sur les pages, la gestion de la mémoire virtuelle et tout le reste... mais j'ai bien compris que je n'irai pas loin avec ma méthode.

Auriez vous peut etre une autre méthode a me proposer ?

Merci beaucoup :-)

[seeme]

Personnellement, j'utilise l'outil valgrind qui est simple à utiliser et donne les fuites mémoires (les erreurs d'allocations, de delete..).

C'est précis et efficace.

[Ange_blond]

Personnellement, j'utilise l'outil valgrind qui est simple à utiliser et donne les fuites mémoires (les erreurs d'allocations, de delete..).

J'en ai entendu parler oui, mais comme je suis sous windows...

[stardeath]

sous windows il y a visual leak detector, la crt (_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF )

après je ne sais pas si ça marche ailleurs que sous visual studio.

[Ange_blond]

J'ai essayé avec la CRT, c'est pas trop facile a mettre en place, alors j'ai preferé Visual Leak Detector.
Le résultats sont là, il y a bien quelques fuites, mais rien de l'ampleur de ce que j'imaginais...
Je vais commencer par regler les soucis exitants et refaire des tests pour voir si ça a changé quelque chose.

Je ne clos pas le topic car je suis toujours a la recherche d'une maniere de "suivre" l'état de la mémoire avec précision au fur et a mesure des allocations.

Merci.

[seeme]

Une autre solution qui t'obligerais à recoder pas mal de chose serait d'utiliser des smartpointers ou un gestionnaire de mémoire..

[Ange_blond]

Une autre solution qui t'obligerais à recoder pas mal de chose serait d'utiliser des smartpointers ou un gestionnaire de mémoire..

J'utilse dejà les smart_ptr sur uen grande partie du code, mais ça n'empeche q'en cas de reference croisée par exemple, on a une fuite... c'est a manipuler avec précautions.

Le gestionnaire de mémoire de windows est beaucoup trop imprécis pour me renseigner efficacement

[seeme]

Par gestionnaire de mémoire, j'avais en tête quelque chose comme une classe singleton qui s'occupe des allocations et qui compte les différentes références.

Plus de null pointer, tout est réservé/libéré proprement.

[stardeath]

vld garde une trace de toutes les allocations mémoires (c'est mieux pour détecter les fuites XD ), après je sais pas si ça peut te convenir.

ps : VLDReportLeaks(); reporte les blocs mémoires non désalloués

[Ange_blond]

Je teste VLD en ce moment, il a détecté quelques fuites en effet, mais pas là où j'esperais en voir... je vais continuer a bosser avec, réduire toutes les fuites, puis je ferai a nouveau des tests pour voir si ça a changé quelque chose.

Merci :-)

[bacelar]

Il y a pas mal d'outils payant comme DevPartner de Compuware ou Purify d'IBM qui ont ce genre de tracker.

Sinon, il y a aussi Pageheap.exe (http://support.microsoft.com/kb/286470), mais c'est très bas niveau.

Utilisez des outils si vous ne maîtrisez pas un minimum les problématiques de mémoire virtuelles, de mémoire physique, de mémoire partagée, et de mapping mémoire.