gdb backtrace e pthread_cond_wait ()

Question

Questo è su una macchina RedHat EL5 w / un kernel 2.6.18-164.2.1.el5 x86_64 usando gcc 4.1.2 e gdb 7.0.

Quando eseguo la mia applicazione con gdb e rompere nel mentre è in esecuzione, molti dei miei discussioni mostrare il seguente stack di chiamate quando faccio un backtrace:

#0  0x000000000051d7da in pthread_cond_wait ()
#1  0x0000000100000000 in ?? ()
#2  0x0000000000c1c3b0 in ?? ()
#3  0x0000000000c1c448 in ?? ()
#4  0x00000000000007dd in ?? ()
#5  0x000000000051d630 in ?? ()
#6  0x00007fffffffdc90 in ?? ()
#7  0x000000003b1ae84b in ?? ()
#8  0x00007fffffffdd50 in ?? ()
#9  0x0000000000000000 in ?? ()

E 'questo un sintomo di un problema comune?
Esiste un problema noto con la visualizzazione dello stack di chiamate in attesa su una condizione?

Answer 1

Il problema è che pthread_cond_wait è scritto in assembly manuale, e apparentemente non ha la descrittore di rilassarsi (richiesto sul x86_64 per rilassarsi la pila) nella build di glibc. Questo problema potrebbe essere stato recentemente fissato qui .

Si può cercare di costruire e installare l'ultima glibc (nota: se si fallisce l'installazione, la macchina diventerà probabilmente non avviabile; approccio con estrema cautela)., O semplicemente vivere con "falsi" tracce dello stack da pthread_cond_wait

Answer 2

In generale, la sincronizzazione è necessaria quando più thread condividono una singola risorsa. In tal caso, quando si interrompe il programma, si vedrà solo 1 thread è in esecuzione (vale a dire, l'accesso alla risorsa) e altri thread sono in attesa all'interno pthread_cond_wait().

Quindi non penso pthread_cond_wait() è di per sé problematico.

Se il programma si blocca con deadlock o performance non in scala, potrebbe essere causato da pthread_cond_wait().

Answer 3

Che assomiglia a una traccia dello stack corrotto per me

Ad esempio:

#9  0x0000000000000000 in ?? ()

Non ci dovrebbe essere il codice a NULL