pthread_cond_signal deadlocks

Quelle pourrait être la cause si un appel à pthread_cond_signal deadlocks? D'après ce que je comprends (man page), il est implémenté en interne avec un mutex, mais qu'est-ce qui pourrait causer le blocage de cette opération interne de verrouillage de mutex?pthread_cond_signal deadlocks

EDIT: Je débogue une application qui semble bloquée à certaines occasions. Quelques-unes des stacktraces ressemblent à ceci:


Thread 1 (Thread 0xf6dff6c0 (LWP 32001)): 
#0 0xffffe410 in __kernel_vsyscall() 
#1 0x00af15de in __lll_mutex_lock_wait() from /lib/tls/libpthread.so.0 
#2 0x00aef3eb in [email protected]@GLIBC_2.3.2() from /lib/tls/libpthread.so.0 
#3 0xf4cc8d83 in xxx

Source

2010-12-03 Krumelur

Est-ce hypothétique, ou voyez-vous cela? –

J'étudie une situation de blocage réel dans une application Linux. – Krumelur

Ne montrez pas ce que fait ce thread, mais ce que tous les threads font: 'thread apply all backtrace'. Vous n'obtenez pas une impasse en n'utilisant qu'un seul thread. –

Eh bien, une chose à chercher peut-être cette mise en garde de la page de manuel, ce qui semble particulièrement applicable:

Les fonctions de l'état ne sont pas async -signal sûr, et ne devrait pas être appelé à partir d'un gestionnaire de signal. En en particulier, l'appel pthread_cond_signal ou pthread_cond_broadcast à partir d'un gestionnaire de signal peut bloquer l'thread appelant.

En dehors de cela, vous pouvez aussi le voir si le mutex interne au sein du pthread_cond_t a été écrasé par une écriture perdue au-delà des limites d'une autre variable.

Source

2010-12-04 04:05:46 caf

Merci, oui je commence à suspecter la mémoire corrompue. Je vais vérifier si une fonction pthread * est utilisée par un gestionnaire de signal. – Krumelur

Répondre

Questions connexes