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 !