[Yes::Engine] Compilation et utilisation du gestionnaire de mémoire

Version imprimable

22/07/2007, 18h24
somberlord

[Yes::Engine] Compilation et utilisation du gestionnaire de mémoire

Bonjour,

je viens de commencer le tutorial sur le Yes::Engine. Mais je n'arrive pas à utiliser les outils de debug, et plus principalement le Gestionnaire de mémoire avec Code::Blocks.

J'ai essayé différentes façon de faire : compiler une bibliothèque statique, compiler les fichiers comme faisant partie du projet, faire hériter ou non le CMemoryManager de CSingleton. Mais ca ne marche pas, il y a plusieurs symptomes :

1) Si je n'utilise pas la classe CSingleton, le programme segfault dès que je fais un new (ce qui est assez génant). Le fichier memory leaks.log est créé, mais il est vide (il n'y a même pas les entêtes)

2) Si j'utilise la classe CSingleton, rien que le fait de l'inclure dans le CMemoryManager.h me sort les erreurs suivantes :
Singleton.h L44 : Yes::CMemoryManager has not been declared
(dans le destroy de CSingleton)

DebugNew.h L30 : Declaration of `operator new` as non-function
ainsi que pour la deuxième déclaration de new

Pour les delete, j'ai l'erreur suivante :
class `Yes::CMemoryManager::Instance` is not a type

Voila, je ne sais plus quoi faire, ca fait deux jours que je me casse la tête à essayer de faire marcher ce gestionnaire de mémoire. Toute aide serait la bienvenue.

Merci d'avance.
23/07/2007, 11h01
Invité

Si je me souviens bien dans le code d'init, il y a un truc qui est loggé avant même d'avoir initialisé le logger, ce qui lance une exception, elle même rattrapée par le logger qui n'existe pas, etc...

C'est dans YesApplication si je me souvient bien.
14/08/2007, 13h25
deadalnix

Pareil, et j'en voit pas le bout.

Qui plus est, le debugger integré a code::block ne m'aide pas beaucoups . . .

EDIT : on va meme pas dans le code d'init :? le probleme viens bien du memory manager
14/08/2007, 15h00
Invité

Oui, si je me souviens bien, c'est à cause du logger qui est fixé dès le début... tu log les execptions du memory manager, qui crashe au demarage faute de logger ou un truc dans le genre. si je me souviens bien, il remonter l'appel de creation du logger, de manière à ne plus avoir ce probleme.

J'ai un solution.

Le probleme viens du fait que le constructeur du memory manager fait appel a un delete, qui lui meme rapelle le memorymanager, et ce, jusqu'a ce que la pile d'appel deborde et que le systeme coupe les vivres a l'application.

Ma solution, c'est pas nickel, mais ca marche :

Dans memorymanager.h :

en public :

Code:

1
2
3
4
5
 
        //----------------------------------------------------------
        // Revoie l'etat de creation du Memorymanager
        //----------------------------------------------------------
        static bool isReady();

en privé :

Code:

1
2
 
       static bool ready;

dans memory manager.cpp :

Avant le constructeur :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
/////////////////////////////////////////////////////////////
/// Initialisation des membres statics
///
////////////////////////////////////////////////////////////
bool CMemoryManager::ready = false;
 
 
/////////////////////////////////////////////////////////////
/// Acesseur sur ready
///
////////////////////////////////////////////////////////////
bool CMemoryManager::isReady(){
	return CMemoryManager::ready;
}

Il nous reste a adapter nos deletes, dans debuNew.h :

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
 
/////////////////////////////////////////////////////////////
/// Surcharge de l'opérateur delete
///
/// \param Ptr : Pointeur sur la zone à libérer
///
////////////////////////////////////////////////////////////
inline void operator delete(void* Ptr) throw()
{
	if(!Yes::CMemoryManager::isReady()){
		free(Ptr);
		return;
	}
    Yes::CMemoryManager::Instance().Free(Ptr, false);
}
 
 
/////////////////////////////////////////////////////////////
/// Surcharge de l'opérateur delete[]
///
/// \param Ptr : Pointeur sur la zone à libérer
///
////////////////////////////////////////////////////////////
inline void operator delete[](void* Ptr) throw()
{
	if(!Yes::CMemoryManager::isReady()){
		free(Ptr);
		return;
	}
    Yes::CMemoryManager::Instance().Free(Ptr, true);
}

Chez moi ca marche impec, donc je propose ;)

15/08/2007, 09h59
somberlord

Merci, au vu des derniers différents tests que j'avais fait, j'avais repéré un appel récursif à delete.

Je vais tester ta solution qui me parait prometteuse, merci beaucoup!!

Par contre, je viens de relire ton code, a quel moment le CMemoryManager::ready est passé à true??

lol, effectivment, j'ai oublié un bout de code, desolé !

le voici :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/////////////////////////////////////////////////////////////
/// Constructeur par défaut
///
////////////////////////////////////////////////////////////
CMemoryManager::CMemoryManager() :
m_File("Memory leaks.log")
{
    // On vérifie que le fichier est bien ouvert
    if (!m_File)
        throw CLoadingFailed("Memory leaks.log", "Impossible d'accéder en écriture");
 
    // Inscription de l'en-tête du fichier
    m_File << "  ========================================" << std::endl;
    m_File << "   Yes::Engine v0.1 - Memory leak tracker " << std::endl;
    m_File << "  ========================================" << std::endl << std::endl;
 
    ready = true;
}

Il est mis a true tout simplement quand le memory manager est pret ;)

16/08/2007, 18h25
somberlord

Merci bien, je vais tester tout ca, et je te tiens au courant.
19/08/2007, 16h49
somberlord

C'est bon, tout marche parfaitement, je vais pouvoir avancer.

Merci beaucoup !!!
20/08/2007, 03h24
deadalnix

Tu devrais mettre un tag resolus dans ce cas, ca aidera surrement quelqu'un d'autre de retrouver ce topic.
20/08/2007, 10h47
somberlord

Euh, il me semble que je l'ai mis, non??