Discussion :

[r0d]

Bonjour à tous,

j'ai un mémory leak dont ne parviens pas à me débarrasser:

Detected memory leaks!
Dumping objects ->
{16050} client block at 0x013DF5E0, subtype c0, 16 bytes long.
First-chance exception at 0x7c809eec in TestIndex_d.exe: 0xC0000005: Access violation reading location 0x0135201c.
an invalid object at $013DF5E0, 16 bytes long

Je n'arrive pas à le localiser car le #d'allocation (ici 16050) n'est jamais le même d'une exécution à l'autre.
Le plus énervant, c'est que je pense être parvenu à trouver le bout de code qui génère cette fuite, car si j'enlève ce bout de code, je n'ai plus de fuite. Mais peut-être est-ce "l'arbre qui cache la forêt"? Car ce bout de code est simple:

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
 
MaMethode()
{
switch:
[...]
case 1:
      ObjetA *a;
 
      while ( (a= m_maFIFO.Get()) )
      {
            ObjetB *b= (ObjetB*) a->GetB();
            // ici, un appel de fonction qui utilise les membres de b (uniquement des int => pas de buffer, ni char*, ni pointeur de façon générale):
            f(b->membre1, b->membre2);
 
            SAFE_DELETE(a);
      }
break;
[...]
}

Si je rajoute SAFE_DELETE(b) avant SAFE_DELETE(a), ça plante.
Je ne comprends pas trop ce qu'il se passe ici. Peut-être y a-t-il un rapport avec le switch?

[Aurelien.Regat-Barrel]

Ou un mauvais cast. Utilise dynamic_cast dans ce genre de cas.
http://c.developpez.com/faq/cpp/?pag...s#DIVERS_casts

ou alors le destructeur de a n'est pas virtuel
http://c.developpez.com/faq/cpp/?pag...UCTEUR_virtuel

[r0d]

Merci pour ton aide

Ou un mauvais cast. Utilise dynamic_cast dans ce genre de cas.
http://c.developpez.com/faq/cpp/?pag...s#DIVERS_casts

En fait je me suis trompé, toutes mes excuses: B n'est pas une classe mais une struct. Je ne peux donc pas faire de dynamic_cast.

ou alors le destructeur de a n'est pas virtuel
http://c.developpez.com/faq/cpp/?pag...UCTEUR_virtuel

En effet, le destructeur de A n'est pas virtuel. Mais le problème n'est pas là car A n'est pas dérivée.

[farscape]

salut,
donc dans la serie j'ai un leak lol,
est ce que toutes les libs et programme utilisent la meme crt ?
pas de melange multi-thread dll et multi-thread static ?

[r0d]

Et bien si, et tu mets le doigts sur un truc qui me pose pas mal de soucis, et par que pour les memory leaks. Certains projets de ma solution doivent être compilés en multithread debug dll, et d'autres en multithread debug tout court.

Quant à la crt, je pense qu'ils utisent toute la même, je vérifirais lundi.

Dans mes cauchemars, l'output de visual est grande comme un écran de cinéma et je vois défiler des memory leaks à l'infini...

[farscape]

donc c'est pas la meme ,un utilise la crt sous forme de dll soit le couple msvrt(d).lib et MSVCR80.DLL (sous VC2005)
soit en static :LIBCMT(d).lib .
ce qui est alloué par une CRT ne peux etre libéré par une autre..
regarde aussi ce lien:
see Potential Errors Passing CRT Objects Across DLL Boundaries.

[r0d]

En effet. Ce lien explique pas mal de mes soucis, merci.
En revanche, ce qui est énervant, c'est que je ne peux rien y faire

encore