Discussion :

[Ginji]

Bijour à tous !

Bon alors voila, je souhaite avoir plus d'info au niveau du dump des memory leaks dans mon code, car actuellement c'est le dump standard qui ne contient donc pas le nom du fichier et la ligne ou à été faite l'allocation suspecte.

G donc rajouté _CRTDBG_MAP_ALLOC au niveau de mes definitions preprocesseurs ... Ce qui est censé rajouter les informations complémentaires que je souhaite, au niveau de l'output window.

Le probléme dans mon cas est que j'ai donc mon application MFC qui est donc un de mes projets du workspace, mais j'ai également plusieurs autres projets librairies (ma lib mathematique, ma lib noyau etc ...).

Quand je trace les appels à new, ca appelle en effet la fonction new surchargé pour le debug, en passant le nom du fichier et la ligne, mais ca seulement pour les new effectués dans mon application MFC executable. Quand je met un breakpoint sur un new d'un de mes projets librairie, je me rend compte que ca appelle bien la fonction new surchargée qui se trouve dans crtdbg.h :

Code :

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

1
2
3
 
inline void* __cdecl operator new(unsigned int s)
{ return ::operator new(s, _NORMAL_BLOCK, __FILE__, __LINE__); }

par contre le __FILE__ et __LINE__ ne sont pas remplis correctement, car je pense qu'il s'agit d'un appel librairie et qu'il ne sait donc pas le nom et la ligne du fichier appellant concerné.

Je me retrouve donc avec ca en sortie :

Code :

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

1
2
3
4
5
6
7
8
9
 
Detected memory leaks!
Dumping objects ->
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {3143} normal block at 0x00940690, 48 bytes long.
 Data: <                > 18 00 00 00 1F 00 00 00 97 00 00 00 06 01 00 00 
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {3142} normal block at 0x009406F0, 48 bytes long.
 Data: <            3   > 1C 00 00 00 A1 00 00 00 01 01 00 00 33 01 00 00 
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {3136} normal block at 0x009405B0, 56 bytes long.
 Data: <            =   > 01 00 00 00 11 00 00 00 17 00 00 00 3D 00 00 00

Ce qui ne me convient pas trop, en effet il detecte que le new a ete appellé au niveau de crtdbg.h ... super mais je le sait ca et je m'en fou.

J'aimerai donc savoir comment je peux faire pour avoir ces informations precises également pour mes projets de librairie !

Ca urge assez, alors si qqun à une solution, merci de me faire signe, je galére assez la !

Tchahhhhaoaooo !!![/code]

[farscape]

et dans tes libs tu a bien mis :

Code :

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

1
2
3
4
5
6
 
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

et quand tu link en debug les libs elles sont en debug aussi ?

[Ginji]

J'ai en effet inséré ce bloc de code au niveau de mes libs ...
Je ne l'avai pas précisé.

Les libs linkés sont bien entendus également dans la configuration Debug.

Mais rien à faire ...
Voici un trace d'un new dans une de mes libs

(CMRAKERNEL.CPP)

Code :

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

1
2
3
4
5
6
 
bool CMRAKernel::Init()
{
      if (!m_RoadVision)
         m_RoadVision = new RoadVision();
      [......]

Breakpointé sur le new qui va la :

(CRTDB.H)

Code :

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

1
2
3
 
inline void* __cdecl operator new(unsigned int s)
{ return ::operator new(s, _NORMAL_BLOCK, __FILE__, __LINE__); }

Puis finalement la :

(AFXMEM.CPP)

Code :

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

1
2
3
4
5
6
7
8
9
10
 
void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine)
{
#ifdef _AFX_NO_DEBUG_CRT
	UNUSED_ALWAYS(nType);
	UNUSED_ALWAYS(lpszFileName);
	UNUSED_ALWAYS(nLine);
	return ::operator new(nSize);
#else
[...]

Et à ce niveau lpszFileName contient CRTDB.H au lieu de CMRAKERNEL.CPP ce ki n'est pas du tout ce ke je veux !

Par contre comme je le disai précédememnt, un new executé dans l'app principale contient bien les bonnes infos sur sa localisation.

Y doit y avoir une bidouille à faire pour faire marcher le business, mais je n'ai pas assez d'éxpérienceau niveau des fonction CRT debug heap de Visual !

A l'aiiiddeee !!!

[farscape]

ton projet et tes libs ils sont en accord au niveau du runtime lib: c'est a dire multi thread de partout ou monothread de partout.?
(onglet c++ category: code generation)

[Ginji]

Bon en fait j'ai trouvé la technique en rusant un peu.

Code :

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

1
2
3
4
5
6
7
 
#ifdef _DEBUG
#include <crtdbg.h>
#define DEBUG_NEW new(_NORMAL_BLOCK ,__FILE__, __LINE__)
#else
#define DEBUG_NEW new
#endif

et dans mes cpp de lib je fait un

Code :

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

1
2
3
4
 
#ifdef _DEBUG
#define new DEBUG_NEW
#endif

J'ai essayé de mettre tout ca dans un cpp pour tester, et un new de ce .cpp passe trés bien comme je veux.
Par contre je n'ai pas de pch pour ce projet de lib, alors je sais pas ou mettre le premier bloc !!!

Paske la si je le met dans mon .h du projet qui est inclu un peu partout, g une tonne d'erreurs et je sais pas trop pkoi.

Je galére un peu j'avoue

[Ginji]

Par contre en faisant ca je vai avoir ke les normal block ... si y a des clients blocks ou autre conneries de blocks ca va les zapper ... je v modifier un peu le code

[farscape]

salut,
je te conseille de rajouter un stdafx.h dans projet lib et de rajouter dans l'onglet c++ category precompiled headers :
automatic use of precompiled headers.
j'ai eu le meme pb sur des libs perso ou je n'avais pas de stdafx.h au debut.

[Ginji]

Merci bcp FarScape!

Le pb est désormais résolu