Discussion :

[Cyanatide]

Bonjour.
Voila, je voudrais corriger les fuites de mémoire de mon programme. Étant sous visual studio, je me suis reporté à la page correspondante de la MSDN.
Effectivement, mes fuites de mémoires sont bien listées, cependant je voudrais récupérer les fichiers et les lignes responsable. Toujours selon cette même source, c'est la ligne #define _CRTDBG_MAP_ALLOC qui le gère.

J'ai bien ajouté cette ligne, cependant on ne m'indique toujours pas le fichier et la ligne. En cherchant un peu plus, je suis tombé sur cette page qui me dit que le débug /MTd doit etre activé. Je vais voir dans les propriétés de mon projets j'ai bien la bibliothèque Runtime définie à MTd, pourtant, toujours pas d'info sur les fichiers.

Avez vous une idée de ce qui pourrait bloquer?
Merci.

[stardeath]

bonsoir, quelle version de visual studio? parce que chez moi 2010 ça fonctionne.

après pour vs 2008 et 2010 il y a visual leak detector qui permet d'avoir plus d'infos.

[bacelar]

Question bête, compilez-vous tous les composants en Debug ?

[Cyanatide]

Je suis pourtant bien sous Visual Studio 2010.

Voici mes paramètres de compilations (du moins si c'est ça qui vous intéresse)


Quelque chose n'irait pas?

[bacelar]

Avez-vous bien mis les 3 lignes indiquées dans vos références au début de votre stdAfx.h si vous utilisez les precompiled headers ou au début de chaque .cpp sinon ?

[Cyanatide]

J'ai mit ce code en haut de mon main.cpp:

Code :

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

1
2
3
4
5
6
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
 
#include "stdafx.h"
#include "threads.h"

Cependant, mon main ne fait qu'appeller un thread (pour mes test de mémoire), attendre qu'il finisse et afficher les fuites de mémoires avant de se clore.

Dois-je utiliser la détection de mémoire uniquement sur mon thread et non sur le main?

[bacelar]

Il faut que les trois lignes soient, directement ou indirectement via include, dans chaque unité de compilation dont on veut tracer le code d'allocation. Par unité de compilation, comprenez .cpp.

Ces 3 lignes de sont pas magiques et ne transforment pas l'espace d'exécution du processus en boite blanche.

Elles ne font que redéfinir les primitives d'allocations mémoires pour qu'elles fournissent les informations nécessaires.

Il faut donc qu'avant chaque définition et déclaration du code à tracer, ces 3 lignes apparaissent.

L'idéal serait donc de les mettre tout au début du StdAfx.h avec les precompiled headers.

Il y a d'autres solutions possibles, mais soit plus intégrées à VS où plus laborieuses.

[Cyanatide]

J'ai bien ajouté ces trois lignes dans le StdAfx.h, mais rien n'a changé sur la sortie.
Je suis bien censé mettre la fonction _CrtDumpMemoryLeaks() à la fin de mon programme, et non à la fin du thread appelé par celui ci n'est ce pas?

[bacelar]

Je suis bien censé mettre la fonction _CrtDumpMemoryLeaks() à la fin de mon programme, et non à la fin du thread appelé par celui ci n'est ce pas?

Oui, mais il faut être sur que tous les autres threads aient terminée leur code de nettoyage.

Cela ne trace les lignes de sources que les allocations faites dans le code compilé avec.

Peut-être que les allocations ce font dans des bibliothèques qui sont déjà compilé et vous n'aurez pas ces informations dans ce cas.

Avez-vous déjà testé cette détection avec une fuite fait sciemment dans le code du projet, pour vérifier que ce type de fuite est détecté ?

[Cyanatide]

Effectivement, j'ai fait un malloc juste avant le _CrtDumpMemoryLeaks() et dans mon thread, le fichier et la ligne m'ont bien été donnée.
Les autres fuites de mémoires doivent donc venir des librairies.
Merci beaucoup pour votre aide précieuse