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