Comment puis-je déboguer ce SIGSEV dans gdb?

Question

Je construis déjà du code de travail, mais je reçois un défaut de segmentation et je n'arrive pas à comprendre ce qui s'est mal passé. gdb intercepte l'erreur, mais ne pointe pas vers une cause évidente. La ligne source qu'elle montre est un nom de fonction, donc elle n'atteint même pas la fonction. Si je regarde le désassemblage de l'instruction, il est toujours en train de mettre en place la pile, donc peut-être que la pile est foirée. Alors, comment dois-je faire pour déboguer cela? C'est dans QNX 6.2, console gdb seulement.

0x0816b829 in __ml (this=0x79b963c, anMultiplier=0) at ../u_matrix.cpp:56 
56  tcMatrix tcMatrix::operator*(float64 anMultiplier) 

0x816b820 <__ml>:  push %ebp 
0x816b821 <__ml+1>:  mov %esp,%ebp 
0x816b823 <__ml+3>:  sub $0x13ac,%esp 
0x816b829 <__ml+9>:  push %edi 
0x816b82a <__ml+10>: push %esi 
0x816b82b <__ml+11>: push %ebx 

Answer 1

L'instruction que vous plantez est push %edi.

Cela signifie très probablement que vous avez un débordement de pile.

Une cause probable de dépassement de pile est une récursion infinie. Si (gdb) where montre le flux sans fin des appels de fonction, c'est votre problème.

Si where montre séquence raisonnable d'appels, d'exécuter à plusieurs reprises info frame et up, à la recherche de cadres avec une taille déraisonnablement grande. Enfin, le problème peut être causé par un changement dans votre environnement d'exécution, et non par quoi que ce soit dans votre programme. Je ne suis pas sûr de ce qu'est l'équivalent QNX de ulimit -s, mais il est possible que votre limite de pile soit simplement trop petite.

Answer 2

Quelque chose de pertinent si faire un "bt" dans gdb?

Answer 3

Vous pouvez également essayer de le vérifier, ce qui peut donner plus d'informations.

Answer 4

"ce" pointeur semble tronqué - 0x79b963c semble être éteint mais cela est possible selon la façon dont les objets sont initialisés. Essayez

print * ce

et voir si des données est logique ou est des ordures. Il semble également que votre source ne correspond pas à l'exécutable - la ligne que vous avez dans l'exemple ressemble à une déclaration de remplacement d'opérateur et non à quelque chose d'exécutable.

Je voudrais ignorer la ligne particulière, recherchez toute la fonction _ml dans la source et essayer d'imprimer quelques variables locales pour voir si vous êtes peut-être dans une boucle ou une autre portée qui les aurait. Je suppose que vous avez un opérateur de multiplication de matrice où une matrice est multipliée par un flottant - très probablement, c'est quelque chose comme un index hors limites, un problème de quelque sorte où vous avez couru en dehors de la portée de la mémoire et corrompu la pile.

Comme dit inconnu, essayez aussi bt - si elle revient avec beaucoup de ??(), alors vous avez une pile corrompue.

Answer 5

Après la réponse de la Russie occupée:

ulimit travaux de QNX, mais il est illimité par défaut.

J'expérimenter

ldrel -S2M -L yourexecutablename

pour régler la première allocation de pile/paresse pour voir si coredumps reproduiront. Vous pouvez également utiliser l'option -N de QCC pour augmenter la taille de la pile initiale.

Answer 6

QNX ne semble maintenant soutenir valgrind (au moins de 6,5 et suivantes):

http://community.qnx.com/sf/frs/do/viewRelease/projects.valgrind/frs.valgrind.valgrind_3_10