TLDR :Assurez-vous que vous ne verrouillez pas un mutex qui a été détruit/n'a pas été initialisé.
Bien que l'OP ait sa réponse, j'ai pensé partager mon problème au cas où quelqu'un d'autre aurait le même problème que moi.
Notez que l'assertion est dans __pthread_mutex_lock et non dans le déverrouillage. Cela, pour moi, suggère que la plupart des autres personnes ayant ce problème ne déverrouillent pas un mutex dans un thread différent de celui qui l'a verrouillé; ils verrouillent juste un mutex qui a été détruit.
Pour moi, j'avais un cours (appelons-le Foo ) qui a enregistré une fonction de rappel statique avec une autre classe (appelons-la Bar ). Le rappel passait une référence à Foo et verrouillait/déverrouillait occasionnellement un mutex membre de Foo .
Ce problème est survenu après le Foo instance a été détruite alors que le Bar l'instance utilisait toujours le rappel. Le rappel recevait une référence à un objet qui n'existait plus et, par conséquent, appelait __pthread_mutex_lock sur la mémoire des ordures.
Remarque, j'utilisais le std::mutex de C++11 et std::lock_guard<std::mutex> , mais comme j'étais sous Linux, le problème était exactement le même.
Solide comme un roc pendant 4 jours d'affilée. Je déclare victoire sur celui-ci. La réponse est "erreur stupide de l'utilisateur" (voir les commentaires ci-dessus). Un mutex ne doit être déverrouillé que par le thread qui l'a verrouillé. Merci de m'avoir supporté.
J'ai été confronté au même problème et google m'a envoyé ici. Le problème avec mon programme était que dans certaines situations, je n'initialisais pas le mutex avant de le verrouiller.
Bien que la déclaration dans la réponse acceptée soit légitime, je pense que ce n'est pas la cause de cette affirmation ratée. Parce que l'erreur est signalée sur pthread_mutex_lock (et pas déverrouiller).
De plus, comme toujours, il est plus probable que l'erreur se trouve dans le code source du programmeur plutôt que dans le compilateur.