Discussion :

[Sleeping Lionheart]

Bonsoir à tous,

Excusez le titre du post je ne suis pas très inspiré

Mon problème est le suivant :

J'ai un pointeur qui est au départ initialisé à NULL, puis je fais une allocation mémoire pour un objet, le pointeur prends alors comme valeur l'adresse de l'objet. J'en viens maintenant au problème, je me rends compte que mon objet, qui est en fait un singleton, est alloué 2 fois sans avoir été détruit entre les deux allocations. Ce qui est bizarre c'est que je vérifie si le pointeur vaut NULL avant de faire l'allocation, en passant le debugger (gdb) je me suis rendu compte que le pointeur pointait encore sur la même adresse non nulle et lorsque vînt le moment de passer la condition avec laquelle je vérifie si le pointeur est à NULL, ce qui n'était pas le cas bien entendu, et ben il m'évalue tout de même l'expression comme vraie.

Pour l'instant j'en rigole nerveusement mais je pense que bientôt ça ne me fera plus rire du tout, surtout lorsque l'objet en question est un gestionnaire de ressources

Je vous remercie d'avance de l'aide que vous pourrez m'apporter et vous souhaite une bonne soirée.

[gl]

Peut-on voir le bout de code concerné ?

A tout hasard, ne serait-ce pas une simple erreur d'étourderie : un = à la place de == ?

[Sleeping Lionheart]

Malheureusement non, voici la méthode qui fait l'allocation du singleton :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
static inline T *Get_Instance()
{
     if (m_pSingleton == NULL)
     {
         m_pSingleton = new T;
     }
 
     return ( static_cast<T*>(m_pSingleton) );
}

comme vous pouvez le voir j'utilise bien l'operateur de comparaison ==

[alexrtz]

est alloué 2 fois sans avoir été détruit entre les deux allocations. Ce qui est bizarre c'est que je vérifie si le pointeur vaut NULL avant de faire l'allocation, en passant le debugger (gdb) je me suis rendu compte que le pointeur pointait encore sur la même adresse non nulle et lorsque vînt le moment de passer la condition avec laquelle je vérifie si le pointeur est à NULL, ce qui n'était pas le cas bien entendu, et ben il m'évalue tout de même l'expression comme vraie.

Attention : détruire un pointeur ne fait pas passer sa valeur à NULL.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>
 
using namespace std;
 
int main()
{
  int *a = new int;
 
  delete a;
 
  cout << hex << a << endl;
 
  return 0;
}

Sortie :

Code :

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

0x87a1008

Tu dois avoir un delete non suivi de

Code :

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

pointeur = NULL;

[Sleeping Lionheart]

oui bien entendu je sais tout ça, mais la comme je l'ai dit, le pointeur n'est pas détruit, c'est là tout le problème.
Le pointeur pointe toujours sur la même adresse mémoire, du moins c'est ce que le debugger m'indique.

Et de toute façon l'expression m_pSingleton == NULL devrait être fausse, ce qui n'est pas le cas.

[JolyLoic]

Question bête : Tu as des DLL dans ton appli ?

[Sleeping Lionheart]

Oui j'en charge une dynamiquement avec LoadLibrary et tout le tintoin.

[JolyLoic]

En gros, si tu as une lib statique qui déclare une variable globale ou statique (comme ton m_pSingleton), que cette lib est inclue (statiquement donc) dans n DLL dans un même programme, cette variable existe en n exemplaires dans ton programme : Bref, c'est le bordel.

Si tu es dans ce cas, trois solutions (du moins à ma connaissance) :
- Déclarer une telle variable non plus dans une lib statique, mais dans une lib dynamique
- Supprimer les libs dynamiques pour tout lier statiquement
- Utiliser un autre mécanisme qu'une variable statique pour stocker cette information, comme par exemple une zone de mémoire partagée nommée (ici, l'important n'est pas le partage, mais le nommage, qui fait qu'on peut y accéder depuis n dlls sans soucis).

[Sleeping Lionheart]

OK, en fait je n'ai pas précisé les choses mais je vais le faire tout de suite :

Mon appli utilise 3 libs statiques et une en dynamique chargée depuis le code. L'objet qui est un singleton est créé à partir d'une classe générique comme vous l'avez sûrement constaté. La dll dynamique a été construite elle-même sur des libs liées en dynamique et sur une des 3 libs statique évoqués précédement. De plus une des libs statiques utilise tinyxml, donc je me retrouve avec une 4ème lib statique.

Bref c'est tout de même un beau bordel.

Dois-je vraiment passer toutes mes libs statique en dynamique ?

L'objet dont on parle (le gestionnaire de ressource) n'est pas le seul singleton créé avec cette méthode. Il doit y en avoir 4 à 5 autres et ceux-là ne rencontrent pas le problème.

[mailaka]

- Utiliser un autre mécanisme qu'une variable statique pour stocker cette information, comme par exemple une zone de mémoire partagée nommée (ici, l'important n'est pas le partage, mais le nommage, qui fait qu'on peut y accéder depuis n dlls sans soucis).

Salut. Pratiquement, comment faire cette zone de memoire partagee ?

[JolyLoic]

Avec des appels spécifiques à l'OS. De tête, sous windows, CreateFileMapping et MapViewOfFile.

[Sleeping Lionheart]

Bon je vais essayer de me débrouiller, merci quand même de votre aide.

Bonne journée.

[Médinoc]

Et si tu suis ce qu'a expliqué JolyLoic, pense à inclure l'ID du processus dans le nom de ta mémoire "partagée".