Discussion :

[randriano]

Bonjour!

Klocwork l'analyseur de code statique dit que: Possible memory leak. Dynamic memory stored in 'pSETEndFittingProductFamilies' allocated through function 'new' dans ma partie de code:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
	else
	{
      m_pSubEntityTypesToLoad = new CSubEntityTypesToLoad();
      CSubEntityTypeToLoad* pSETConnectedSemiEquipments = new CSubEntityTypeToLoad(enEProcessSETConnectedSemiEquipments, NULL);
      CSubEntityTypeToLoad* pSETEquProductFamilies = new CSubEntityTypeToLoad(enEProcessSETEquProductFamilies, NULL);
 
      if (m_pSubEntityTypesToLoad && pSETConnectedSemiEquipments/* && pSETEquProductFamilies*/)
      {
         m_pSubEntityTypesToLoad->push_back(pSETConnectedSemiEquipments);
         m_pSubEntityTypesToLoad->push_back(pSETEquProductFamilies);
      }		
	}

alors qu'il semble, j'en suis sur qu'il n'y en a pas
Il s'agit en fait d'une classe héritant un std::vector<>

Il y a bien:

Code :

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

1
2
3
4
5
6
7
void CVectorSubEntityTypesToLoad::Clear()
{
	for(long i = 0; i < (long)size(); i++)
		delete at(i);
 
	clear();
}

Pensez vous que le leak est possible?

Source:
TestMemoryLeakVector.zip

[Médinoc]

Eh bien, pour commencer, ce code n'est pas exception-safe, donc si l'un des trois new lance une exception std::bad_alloc parce qu'il n'y a plus de mémoire (ou si l'un des constructeurs lance une exception), il y aura fuite...

Et plus simplement, si le test est faux, tes deux pointeurs locaux seront leakés...

[randriano]

Eh bien, pour commencer, ce code n'est pas exception-safe, donc si l'un des trois new lance une exception std::bad_alloc parce qu'il n'y a plus de mémoire (ou si l'un des constructeurs lance une exception), il y aura fuite...

Et plus simplement, si le test est faux, tes deux pointeurs locaux seront leakés...

Ah bon ! Il y a donc allocation puis s'il y aerreur et l'espace allouée ne sera jamais désallouée?

Mais si aucune exception, il n'est pas POSSIBLE une memory leak?

Pourquoi l'analyseur précise ces 2 lignes seulement:

Code :

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

1
2
      CSubEntityTypeToLoad* pSETConnectedSemiEquipments = new CSubEntityTypeToLoad(enEProcessSETConnectedSemiEquipments, NULL);
      CSubEntityTypeToLoad* pSETEquProductFamilies = new CSubEntityTypeToLoad(enEProcessSETEquProductFamilies, NULL);

[farscape]

salut,
peut être parce qu'il ne voit pas de libération explicite de ces deux pointeurs.
et que le stockage de leur valeur est conditionnel donc risque de fuite.

[randriano]

peut être parce qu'il ne voit pas de libération explicite de ces deux pointeurs.

Si vous parlez de Klocwork: si! Il voit les delete par boucle des objets pointés par des vector<>, list<>, etc.
Mais le dire de Médinoc m'intrigue un peu:

si l'un des trois new lance une exception std::bad_alloc parce qu'il n'y a plus de mémoire (ou si l'un des constructeurs lance une exception), il y aura fuite

[Médinoc]

Si vous parlez de Klocwork: si! Il voit les delete par boucle des objets pointés par des vector<>, list<>, etc.

Sauf que si ton if (m_pSubEntityTypesToLoad && pSETConnectedSemiEquipments) n'est pas satisfait, tes pointeurs ne seront jamais ajouté au vecteur et seront leakés...

Mais le dire de Médinoc m'intrigue un peu:

C'est pourtant simple:

• Tu alloues le premier objet CSE, ça marche, le seul pointeur vers cet objet est un pointeur bète dans une variable locale.
• Tu tentes d'allouer le second objet EPF, mais il n'y a plus de mémoire: Une exception bad_alloc est lancée.
• Le seul pointeur vers l'objet CSE est détruit et il n'y a rien pour faire un delete dessus: L'objet CSE est leaké.

[randriano]

Sauf que si ton if (m_pSubEntityTypesToLoad && pSETConnectedSemiEquipments) n'est pas satisfait, tes pointeurs ne seront jamais ajouté au vecteur et seront leakés...

D'accord je comprend maintenant ce cas , il faut ajouter un traitement du genre ??

Code :

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

1
2
3
4
5
6
7
8
   else
      if (!m_pSubEntityTypesToLoad)
      {
         if (pSETEndFittingProductFamilies)
            delete pSETEndFittingProductFamilies;
         if (pSETEquProductFamilies)
            delete pSETEquProductFamilies;
      }

Pour le fait que quelque chose m'intrigue,

Tu tentes d'allouer le second objet EPF, mais il n'y a plus de mémoire: Une exception bad_alloc est lancée

Comment le gérer alors? try catch()?

[Médinoc]

Juste un else devrait suffire, pas besoin d'y mettre un second if en plus.
De plus, inutile de tester tes pointeurs avant le delete:

• Tes pointeurs ne seront jamais nuls car sur tout compilo conforme, new lance une exception en cas d'échec
• Même s'ils sont nuls, delete l'accepte.

Pour le problème, il faut ne pas gérer "manuellement" plus d'une ressource à la fois. Je recommande d'utiliser une classe de pointeur intelligent (ici, même std::auto_ptr<> devrait marcher), sans oublier de "détacher" le pointeur quand tu ajoutes l'objet au vecteur (std::auto_ptr<>::release()).

[randriano]

Pour le problème, il faut ne pas gérer "manuellement" plus d'une ressource à la fois. Je recommande d'utiliser une classe de pointeur intelligent (ici, même std::auto_ptr<> devrait marcher), sans oublier de "détacher" le pointeur quand tu ajoutes l'objet au vecteur (std::auto_ptr<>::release()).

Plein de truc la STL!!

Mais concernant la possible fuite à cause de std::bad_alloc, ça arrive souvent???
J'hésite un peu à la gérer car je ne pense pas que c'est ça que Klocwork soupçonnait non?

[Médinoc]

Ce n'est clairement pas ça qu'il soupçonnait, et typiquement, quand une exception bad_alloc est lancée, tu as d'autres soucis.
Par contre, si un des constructeurs est susceptible de lancer une autre exception, ben...

[randriano]

Et ben C++ et ses soucis, ça n'en finit jamais
Sincèrement, les fuites et autres erreurs qui peuvent être causées par un NEW, je n'y ai jamais pensé jusqu'à maintenant
Peux-tu me donner un exemple de gestion de cela?