TLDR:assicurati di non bloccare un mutex che è stato distrutto/non è stato inizializzato.
Sebbene l'OP abbia la sua risposta, ho pensato di condividere il mio problema nel caso in cui qualcun altro avesse lo stesso problema che ho avuto io.
Si noti che l'asserzione è in __pthread_mutex_lock e non nello sblocco. Questo, per me, suggerisce che la maggior parte delle altre persone che hanno questo problema non stanno sbloccando un mutex in un thread diverso da quello che lo ha bloccato; stanno solo bloccando un mutex che è stato distrutto.
Per me, ho tenuto un corso (chiamiamolo Foo ) che ha registrato una funzione di callback statica con un'altra classe (chiamiamola Bar ). Al callback veniva passato un riferimento a Foo e occasionalmente bloccava/sbloccava un mutex che era un membro di Foo .
Questo problema si è verificato dopo il Foo l'istanza è stata distrutta durante il Bar l'istanza utilizzava ancora la richiamata. Al callback veniva passato un riferimento a un oggetto che non esisteva più e, pertanto, stava chiamando __pthread_mutex_lock sulla memoria spazzatura.
Nota, stavo usando std::mutex di C++11 e std::lock_guard<std::mutex> , ma, dato che ero su Linux, il problema era esattamente lo stesso.
Solido come una roccia per 4 giorni di fila. Sto dichiarando vittoria su questo. La risposta è "stupido errore dell'utente" (vedi i commenti sopra). Un mutex dovrebbe essere sbloccato solo dal thread che lo ha bloccato. Grazie per avermi sopportato.
Ho dovuto affrontare lo stesso problema e Google mi ha inviato qui. Il problema con il mio programma era che in alcune situazioni non inizializzavo il mutex prima di bloccarlo.
Sebbene l'affermazione nella risposta accettata sia legittima, penso che non sia la causa di questa affermazione fallita. Perché l'errore è riportato su pthread_mutex_lock (e non sbloccare).
Inoltre, come sempre, è più probabile che l'errore sia nel codice sorgente del programmatore piuttosto che nel compilatore.