2010-07-19 6 views
9

J'ai rencontré des problèmes de débogage d'un processus multi-thread à l'aide de GDB. J'ai un processus multi-thread qui se scinde en plusieurs (8 ou 9) threads différents, et j'essaie de déterminer le contenu des variables lorsque le constructeur d'une classe appelée XML_File_Data est appelé. Cependant, j'ai rencontré un problème où, après avoir appliqué le point d'arrêt de la fonction correcte à tous les threads et qu'il est évident qu'un point de rupture du thread est touché (le programme arrête temporairement l'exécution), je ne peux pas déterminer quel thread frapper le point d'arrêt. La commandeDétermination du thread correct à déboguer dans GDB

(gdb) thread apply all where 

me donne scandaleusement des informations inutiles sous la forme:

#0 0x004ab410 in __kernel_vsyscall() 
#1 0x05268996 in nanosleep() from /lib/libc.so.6 
#2 0x052a215c in usleep() from /lib/libc.so.6 
#3 0x082ee313 in frame_clock_frame_end (clock=0xb4bfd2f8) 
    at frame_clock.c:143 
#4 0x003a349a in ??() 
#5 0x00b5cfde in thread_proxy() 
    from /cets_development_libraries/install/lib/libboost_thread-gcc41-mt-1_38.so.1.38.0 
#6 0x02c1f5ab in start_thread() from /lib/libpthread.so.0 
#7 0x052a8cfe in clone() from /lib/libc.so.6 

Parmi les 9 processus, 7 ou alors me donne presque exactement que la production, et les informations sur la dernière 2 ISN n'est pas vraiment plus utile (les fonctions situées en bas de la pile des appels ont des noms reconnaissables, mais les fonctions # 0- # 4 récentes ne sont pas reconnaissables).

C'est ce que j'ai jusqu'à présent:

(gdb) gdb 
(gdb) gdb attach <processid> 
(gdb) thread apply all 'XML_File_Data::XML_File_Data()' 

et (après le point d'arrêt est touché)

(gdb) thread apply all where 

pourrait me proposer des débogueurs expérimentés quelques conseils sur ce que je fais mal ou ce que est normalement fait dans cette situation?

Cheers, Charlie

EDIT: Heureusement, j'ai pu découvrir que la cause de l '?? est un code optimisé en cours d'exécution par le débogueur, en plus de ne pas exécuter le débogueur dans le répertoire du fichier exécutable. Toujours pas beaucoup de succès avec le débogage cependant.

Répondre

14

Vous pouvez utiliser la commande fil ou d'info discussions pour trouver le numéro de thread courant après point d'arrêt frappé

(gdb) thread 
[Current thread is 1 (Thread 0xb790d6c0 (LWP 2519))] 
(gdb) 

(gdb) info threads 
    17 Thread 0xb789cb90 (LWP 2536) 0xb7fc6402 in __kernel_vsyscall() 
    16 Thread 0xb769bb90 (LWP 2537) 0xb7fc6402 in __kernel_vsyscall() 
    15 Thread 0xb749ab90 (LWP 2543) 0xb7fc6402 in __kernel_vsyscall() 
    14 Thread 0xb7282b90 (LWP 2544) 0xb7fc6402 in __kernel_vsyscall() 
    13 Thread 0xb5827b90 (LWP 2707) 0xb7fc6402 in __kernel_vsyscall() 
    12 Thread 0xb5626b90 (LWP 2708) 0xb7fc6402 in __kernel_vsyscall() 
    11 Thread 0xb5425b90 (LWP 2709) 0xb7fc6402 in __kernel_vsyscall() 
    10 Thread 0xb5161b90 (LWP 2713) 0xb7fc6402 in __kernel_vsyscall() 
    9 Thread 0xb4ef9b90 (LWP 2715) 0xb7fc6402 in __kernel_vsyscall() 
    8 Thread 0xb4af7b90 (LWP 2717) 0xb7fc6402 in __kernel_vsyscall() 
    7 Thread 0xb46ffb90 (LWP 2718) 0xb7fc6402 in __kernel_vsyscall() 
    6 Thread 0xb44feb90 (LWP 2726) 0xb7fc6402 in __kernel_vsyscall() 
    5 Thread 0xb42fdb90 (LWP 2847) 0xb7fc6402 in __kernel_vsyscall() 
    4 Thread 0xb40fcb90 (LWP 2848) 0xb7fc6402 in __kernel_vsyscall() 
    3 Thread 0xb3efbb90 (LWP 2849) 0xb7fc6402 in __kernel_vsyscall() 
    2 Thread 0xb3cfab90 (LWP 2850) 0xb7fc6402 in __kernel_vsyscall() 
* 1 Thread 0xb790d6c0 (LWP 2519) 0xb7fc6402 in __kernel_vsyscall() 
(gdb) 

Un astérisque `* » à gauche du numéro de fil de gdb indique le thread courant . Voir here.

14

Je me retrouve à faire tout le temps:

> t a a f 

court pour:

> thread apply all frame 

Bien sûr, d'autres variantes sont possibles:

> t a a bt 3 

qui imprime le fond 3 cadres de la pile de chaque thread. (Vous pouvez également utiliser des nombres négatifs pour obtenir les N premières images de la pile)

Questions connexes