Discussion :

[LoDev]

Salut � tous,

Je suis un peu en panne d'id�es... et je me demande dans quel sens chercher.

Mon application plante s�v�re, crash complet.
Pour avoir des infos, j'utilise gdb lancement sur la console. Je r�sout les probl�mes de lib�ration de m�moire...
Puis, je teste de nouveau. Plus de soucis avec gdb ! So, le probl�me doit �tre parti.
Confiant, je lance sans... 1er test, crash... et ainsi de suite.

Il doit avoir une histoire de gestion de la m�moire qui doit �tre diff�rente avec gdb (qui doit s�curiser !), mais o�.

Si quelqu'un a une piste, une id�e.

Merci

[mala92]

salut,

As-tu activer la g�n�ration de coredump ?

[bacelar]

Il doit avoir une histoire de gestion de la m�moire qui doit �tre diff�rente avec gdb (qui doit s�curiser !), mais o�.

Ca ne s�curise pas, �a instrumente.

Le but n'est pas de sauver les meubles parce que c'est programm� comme un cochon mais de donner les informations n�cessaires pour corriger ce code de cochon.

L'instrumentation n'est pas neutre d'un point de vue gestion m�moire.
Cela peux transformer un programme bugg� qui crash en un programme bugg� qui crash ou pas. Mais le programme est toujours bug�e.

Utilisez les bonnes options pour la d�tection des cochonneries m�moires (fonction de votre compilateur).

Si c'est toujours le brouillard, sous Windows, DrWatson permet d'avoir des dump lors de crashs et g�n�rez la database des symboles lors de la compilation pour que les outils d'analyses post-mortem puisse indiquer la source du probl�me.

[Ngork]

Si tu veux d�tecter les fuites de m�moire dynamique, je te sugg�re la biblioth�que mpatrol qui m'a souvent (trop souvent ! ) permis de corriger mes propres stupidit�s !
L'usage est simple, tu compiles avec mpatrol, tu lances puis apr�s l'arr�t tu r�cup�res le log et tu peux voir tes fuites de m�moire ...

Sinon, tu as la bonne vieille m�thode consistant � relire ton code !