2010-02-02 6 views
18

Kennt jemand einen Weg von einem pthread_t zu dem, was GDB mit info threads anzeigt? Sopthread_t to gdb Thread-ID

ich habe:

(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 

Wer weiß, wie ich herausfinden, welcher Thread ist das? Es scheint 22768 zu sein, aber keiner meiner Threads geht so niedrig.

+0

Was O ist, dass Linux? –

+0

Ja, tut mir leid. Linux. –

+0

Ich war dabei, das gleiche zu fragen .. aber mein Problem ist schlimmer - ich muss pthread_id zuerst aus dem Kontext wiederherstellen (es ist eine eingebettete Bibliothek in anderen Prozess-Thread läuft .. ew) –

Antwort

8

Der Wert von pthread_t entspricht nicht der systemabhängigen Thread-ID dieses Threads (in Linux gettid(2)), die Sie in GDB sehen.

AFAIK, es gibt keine Funktion, um zwischen den beiden zu konvertieren. Sie müssen das selbst im Auge behalten.

+2

Das ist richtig. Siehe Antwort unter * http: //stackoverflow.com/questions/558469/how-do-i-get-a-thread-id-from-an-arbitrary-pthread-t/558815#558815* für zusätzliche Informationen. – jschmier

+0

Ah, danke. Ich werde es dort packen, wo es mich interessiert, an welchem ​​Thread Dinge auftreten. –

+1

Eigentlich scheint dies veraltet und ich muss syscall (SYS_gettid) verwenden; stattdessen. –

17

Neue Versionen von GDB geben tatsächlich den Wert pthread_t im info thread aus, was die Zuordnung von pthread_t mit der Thread-Nummer trivial macht.

Zum Beispiel mit 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 druckt: '* 1 Prozess 22749 0x000000385c8cd372 in select() von/lib64/libc.so.6' GDB 7.0.1 druckt: ' * 1 Thema 22749 0x000000385c8cd372 in select() von/lib64/libc.so.6' gdb 7,2-55,1 druckt: '* 1 Thema 0x40c68940 (LWP 22749) 0x000000385c8cd372 in select() von/lib64/libc.so.6' So ist die' gDB 7.0' Aussage ist ein bisschen verschwommen. – Vlad