Héritage boucle infinie dans une dll

Version imprimable

Bonjour
En simplifiant, j'ai crée une dll avec l'héritage suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 // Dans Jeu.h class CJeu {} // Dans Joueur.h class CJeu; class CJoueur { CJoueur (CJeu* _jeu); } // Dans JoueurIA.h #include "Joueur.h" class CJoueurIA:public CJoueur { CJoueurIA(CJeu* _jeu); }
En appelant le constructeur de CJoueurIA le programme plante à cause d'une boucle infinie. Incompréhensible en assembleur ??? .

Un post sur un forum parle de précompilation sans explications, de header qui s'entrappelent ... Savez-vous ce qu'ils veulent dire ?
Voyez-vous d'où peut venir le bug ?

Merci pour toute réponse

10/06/2009, 00h44
JulienDuSud
Peut-on voir le contenu de tes constructeurs ?

Comme tes classes ne possèdent pas de constructeur par défaut, appelles-tu bien le constructeur de Joueur dans JoueurIA ?
Code:

1 2 3 4 5 CJoueurIA::CJoueurIA( CJeu* _jeu ) : CJoueur( _jeu ) { }

Voici mes constructeurs :

Code:

1
2
3
4
5
6
7
8
CJeu::CJeu(void){...}
 
CJoueur::CJoueur(CJeu* _parent):m_Parent(_parent)
{...}
 
 
CJoueurIA::CJoueurIA(CJeu* _parent):CJoueur(_parent)
{...}

10/06/2009, 13h04
JulienDuSud

Si tu as une boucle infinie dans le constructeur, et que tu nous montres pas le constructeur, on peut pas vraiment deviner :zoubi:
10/06/2009, 13h16
MABB

Ce n'est pas le code qui est à l'intérieur du constructeur qui provoque la boucle inifinie. C'est à la sortie du constructeur de CJoueurIA.
10/06/2009, 13h31
buzzkaido

Quelles opérations fais-tu dans les différents constructeurs ?

Notamment sur le _parent ?

Si tu as une boucle infinie, tu as une boucle quelque part. Or, dans le code que tu montres, il n'y a aucun signe de boucle. Que veux-tu qu'on cherche comme problème ?
Ce code ne provoque aucun bug:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
#include <iostream>
 
using namespace std;
 
class CJeu
{
};
 
class CJoueur
{
public:
   CJeu* jeu;
 
   CJoueur( CJeu* _jeu ) :
      jeu( _jeu )
   {
	   cout << "Constructeur joueur" << endl;
   }
};
 
class CJoueurIA : public CJoueur
{
public:
   CJoueurIA( CJeu* _jeu ) :
      CJoueur( _jeu )
   {
	   cout << "Constructeur joueur IA" << endl;
   }
};
 
int main()
{
   CJeu jeu;
   CJoueurIA joueurIA( &jeu );
   CJoueur& joueur = joueurIA;
 
   cout << joueur.jeu << "==" << joueurIA.jeu << endl;
   return 0;
}

Dans le constructeur de CJoueur le programme boucle inifiniment sur après

Code:

m_Logger = new CLogger(Nomdechemin);

Avec l'architecture suivante :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
CJeu::Create()
{
J1 = new CJoueurIA(this);
// Plantage avant
}
 
// CJoueurJA appelle le constructeur de CJoueur
CJoueur::CJoueur(CJeu* _parent, int numjoueur)  // j'avais oublié numjoueur
{
char _file_log[32];
	string _num = ToString(m_NumJoueur).c_str();
	sprintf(_file_log, "%s\Joueur_%d.log", m_Parent->GetParent()->GetLogDirectoryName().c_str(), m_NumJoueur);
 
Log = new CLogger(_file_log);  // ne va pas plus loin , boucle infinie en fin de constructeur de CLogger
 
}
 
CLogger::CLogger(const std::string& Filename):m_File(Filename.c_str()), filename(Filename)
{		
//Rien
}
// boucle infine ici
 
// dans la déclaration de CLogger, en private
ofstream m_File;
string filename;

Le logger est utilisé pour une autre classe avant l'erreur et fonctionne.

J'espère que ce code vous aidera. merci pour votre aide.

10/06/2009, 22h58
JulienDuSud

Si ton code respecte exactement cette architecture, ça m'étonnerait très très fortement que tu aies un problème de boucle infinie, tu n'en a littéralement pas.

Si tu ne peux pas donner plus de code, lance un debugger, tu as sûrement un problème avec l'un des pointeurs que tu gère. (et au passage, rajoute un \ avant Joueur dans ton sprintf, là tu y imprimes l'entier qui représente J et non le caractère \ suivi de J.)

En même temps, les variables que tu as nommé m_ sont globales ? Car si elles sont (selon une certaine convention obscure) membres de ta classe CJoueur, je vois pas comment tu peux pointer sur quelque chose alors que tu n'as pas initialisé le pointeur, même chose pour l'entier.
11/06/2009, 02h37
nicroman
Moi je soupconne fortement le constructeur de string ;)
Lors de l'appel Log = new CLogger(_file_log);

Parceque juste avant on a:
Code:

1 2 3 4 char _file_log[32]; string _num = ToString(m_NumJoueur).c_str(); sprintf(_file_log, "%s\Joueur_%d.log", m_Parent->GetParent()->GetLogDirectoryName().c_str(), m_NumJoueur);
et que si ce code est 'safe', je veux bien me pendre !! :D

32 caractères pour stocker un chemin de fichier... c'est un peu court... MAX_PATH à la rigueur (4096 sous windows)... Et si ca dépasse... adieu le 0 terminateur de la chaine... enfin bref....

Je ne suis même pas sur que le string _num = ToString(m_NumJoueur).c_str(); soit bien raisonnable ;)

Maintenant je suis très étonné que le compilo ne detecte pas une corruption de pile immédiatement (Visual 'plante' avec un first-chance exception dès le sprintf chez moi, et en tout cas, il me met de gros warnings rouges lors de l'utilistation de sprintf en me disant, c'est pas safe comme fonction, utilise _sprintf(_file_log,32,....)).
11/06/2009, 09h15
white_tentacle

Citation:

Moi je soupconne fortement le constructeur de string

S'il s'agit bien de std::string, alors oublie tes soupçons. Sauf éventuellement si tu compiles avec borland C++, mais sinon, oublie.

Citation:

string _num = ToString(m_NumJoueur).c_str();

Bizarre ça de passer par .c_str pour le remettre dans une string. Cela dit, ce n'est pas ce qui pose problème.

Citation:

Maintenant je suis très étonné que le compilo ne detecte pas une corruption de pile immédiatement (Visual 'plante' avec un first-chance exception dès le sprintf chez moi, et en tout cas, il me met de gros warnings rouges lors de l'utilistation de sprintf en me disant, c'est pas safe comme fonction, utilise _sprintf(_file_log,32,....)).

Visual ferait mieux de te dire d'utiliser des std::string et boost::format ;).

Mais c'est clair que si file_log est trop petit, tu as un débordement de buffer, et là, tu peux avoir tout et n'importe quoi (incluant une boucle infinie). Comme il est alloué sur la pile, tu corromps effectivement bien ta pile.
11/06/2009, 21h29
MABB

Merci white_tentacle et à vous autre.
C'était bien un débordement du buffer de char.