2010-10-19 26 views
0

Je débogue un processus avec plusieurs threads dans GDB. J'ai compilé le fichier source unique avec le drapeau -g. Cependant, lors de l'exécution dans GDB, le scénario suivant se produit:GDB Quirks avec processus de thread

Program received signal SIGSEGV, Segmentation fault. 
[Switching to Thread 0xb7fe2b70 (LWP 2604)] 
0x00000011 in ??() 

Avant l'interrupteur, le fil particulier exécute une sleep(5);

Pourquoi ne peut GDB identifier le point à partir duquel le code « crashait »?

+0

Quelle version de GDB? – ninjalj

+0

GDB 7.1-34.fc13 –

Répondre

3

0x00000011 n'est pas une adresse valide, surtout pas pour le code. Cela nous indique qu'il n'y a pas de code (donc pas de fonction) à 0x00000011. Et cela nous dit que votre pile est corrompue. Sans une pile «fonctionnelle», gdb est incapable de comprendre comment votre thread s'est retrouvé à l'endroit où il se trouve, car il n'enregistre aucun appel par défaut et ne dépend donc que de la pile.

EDIT Notez que sur x86 vous allez vous retrouver avec le même comportement que vous avez décrit par code comme

_start: 
    mov eax,0x11 
    jmp eax 

Cela conduit à un saut/branche à une région (0x11) où il n'y a pas code et par conséquent pas de symboles de débogage non plus. Cela peut arriver dans un cas comme dans mon exemple, mais aussi si la pile est surchargée (corrompue) et que le retour renvoie une adresse invalide (comme 0x11)

+1

Les piles d'autres threads ne sont peut-être pas corrompues - regardez leurs backtraces en utilisant 'thread apply all backtrace'. Je ne peux pas dire si cela sera utile dans ce cas-ci. –