2010-02-02 4 views
18

Est-ce que quelqu'un sait comment passer d'un pthread_t à ce que GDB affiche avec des threads d'information?pthread_t à gdb ID de thread

J'ai donc:

(gdb) info threads 
    37 Thread 22887 0xb7704422 in __kernel_vsyscall() 
    36 Thread 22926 0xb7704422 in __kernel_vsyscall() 
    35 Thread 22925 0xb7704422 in __kernel_vsyscall() 
    34 Thread 22924 0xb7704422 in __kernel_vsyscall() 
    33 Thread 22922 0xb7704422 in __kernel_vsyscall() 
    32 Thread 22921 0xb7704422 in __kernel_vsyscall() 

(gdb) p m_messageQueue->m_creationThread 
$3 = 2694822768 
(gdb) p/x m_messageQueue->m_creationThread 
$4 = 0xa09fbb70 

Est-ce que quelqu'un sait comment je savoir quel fil est ce? Il semblerait que ce soit 22768, mais aucun de mes fils ne va si bas.

+0

Quel système d'exploitation est que, Linux? –

+0

Oui, désolé. Linux. –

+0

J'étais sur le point de demander la même chose ... mais mon problème est pire - j'ai besoin de récupérer pthread_id d'abord à partir du contexte (c'est une bibliothèque intégrée exécutée dans un autre thread de processus .. ew) –

Répondre

8

La valeur de pthread_t n'est pas la même que l'ID de thread dépendant du système de ce thread (sous Linux gettid(2)) que vous voyez dans GDB. Autant que je sache, il n'y a pas de fonction à convertir entre les deux. Vous devez suivre cela vous-même.

+2

Ceci est correct. Voir la réponse à * http: //stackoverflow.com/questions/558469/how-do-i-get-a-thread-id-from-an-arbitrary-pthread-t/558815#558815* pour plus d'informations. – jschmier

+0

Ah, merci. Je vais l'attraper là où je me soucie de ce qui se passe les choses sur le fil. –

+1

En fait, il semble que ce soit déprécié et je dois utiliser syscall (SYS_gettid); au lieu. –

17

Les nouvelles versions de GDB affichent réellement la valeur de pthread_t dans le info thread, ce qui rend l'association de pthread_t avec le numéro de thread trivial.

Par exemple, en utilisant GDB 7.0:

cat t.c 
#include <pthread.h> 

void *fn(void *p) 
{ 
    sleep(180); 
} 

int main() 
{ 
    pthread_t pth1, pth2; 
    pthread_create(&pth1, 0, fn, 0); 
    pthread_create(&pth2, 0, fn, 0); 
    pthread_join(pth1, 0); 
    return 0; 
} 

gcc -g -m32 -pthread t.c && gdb -q ../a.out 

(gdb) r 
[Thread debugging using libthread_db enabled] 
Using host libthread_db library "/lib64/libthread_db.so.1". 
[New Thread 0xf7e56b90 (LWP 25343)] 
[New Thread 0xf7655b90 (LWP 25344)] 

Program received signal SIGINT, Interrupt. 
0xffffe405 in __kernel_vsyscall() 
(gdb) info thread 
    3 Thread 0xf7655b90 (LWP 25344) 0xffffe405 in __kernel_vsyscall() 
    2 Thread 0xf7e56b90 (LWP 25343) 0xffffe405 in __kernel_vsyscall() 
* 1 Thread 0xf7e576b0 (LWP 25338) 0xffffe405 in __kernel_vsyscall() 
(gdb) up 2 
#2 0x080484e2 in main() at t.c:13 
13 pthread_join(pth1, 0); 
(gdb) p/x pth1 
$1 = 0xf7e56b90 ## this is thread #2 above 
(gdb) p/x pth2 
$2 = 0xf7655b90 ## this is thread #3 above 
+0

GDB 6.8-27 impressions: '* 1 22.749 procédé 0x000000385c8cd372 dans select() du/lib64/libc.so.6' BDG 7.0.1 impressions: ' * 1 Discussion 22749 0x000000385c8cd372 dans select() à partir de/lib64/libc.so.6' gdb 7.2-55.1 imprime: '* 1 Thread 0x40c68940 (LWP 22749) 0x000000385c8cd372 dans select() from/lib64/libc.so.6' Donc l'instruction' GDB 7.0' est un peu flou. – Vlad

Questions connexes