Discussion :

[trollichinelle]

Bonjour � tous,

dans le d�veloppement d'un �xecutable cod� en c++ j'utilise r�guli�rement gdb sans �tre un expert de l'outil,
je me heurte depuis quelques temps � des plantages peu r�guliers mais que je trouve assez al�atoires (avec les m�mes donn�es le plantage n'est pas syst�matique)

l'analyse du fichier core me donne dans ces cas toujours un r�sultat semblable qui me laisse songeur:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
Program terminated with signal 11, Segmentation fault.
...
(gdb) bt
#0  0x00000030e907324d in ?? ()
#1  0x0000000000000000 in ?? ()

est-ce que �a parle � quelq'un?

par ailleurs difficile pour moi de lancer l'ex�cution sous gdb car le bug n'est pas forc�ment reproductible et les �x�cutions tr�s longues


merci de votre aide par avance!

[pfxxx]

c'est presque normal ...

ta pile est bousill�e, quand gdb veut l'utiliser pour retrouver l'adresse/nom des fonctions appelantes, il affiche ce qu'il peut : c'est � dire pas grand chose

1/ Le bug de ton programme alt�re (au minimum) les infos de la pile
par exemple, une var tableau sur la pile dont on explose l'index
memset(mavar, 0, tailleDelirante)
2/ l'exception se produit, et gdb prend la main

3/ il parcourt la pile et essaie d'associer des noms/infos aux adresses.
Pas de bol, les adresses sont d�lirantes, donc gdb ne peut pas afficher autre chose que des valeurs

La difficult� dans ce cas, c'est que le bug se produit bien avant que gdb ne prenne la main.
La 1� chose � faire est de relire le code et de regarder tout ce qui ressemble � des memset/memcpy

sinon tu peux mettre des watchpoint sur les adresses de retour dans la pile. D�s que le bug de ton prog commence � �craser la pile, gdb prend la main.
(regarde la doc gdb sur 'awatch' et surtout http://www.outflux.net/blog/archives...s-they-happen/

sinon tu peux truffer tes sources de assert() pour essayer de d�tecter les pb au plus t�t

[trollichinelle]

je vais me pencher l�-dessus, merci de ton aide