TLDR:asegúrese de no bloquear un mutex que se haya destruido/no se haya inicializado.
Aunque el OP tiene su respuesta, pensé en compartir mi problema en caso de que alguien más tenga el mismo problema que yo.
Observe que la afirmación está en __pthread_mutex_lock y no en el desbloqueo. Esto, para mí, sugiere que la mayoría de las personas que tienen este problema no están desbloqueando un mutex en un hilo diferente al que lo bloqueó; solo están bloqueando un mutex que ha sido destruido.
Para mí, tenía una clase (Llamémosla Foo ) que registró una función de devolución de llamada estática con alguna otra clase (Llamémoslo Bar ). La devolución de llamada estaba pasando una referencia a Foo y ocasionalmente bloqueaba/desbloqueaba un mutex que era miembro de Foo .
Este problema ocurrió después del Foo instancia fue destruida mientras el Bar instancia todavía estaba usando la devolución de llamada. La devolución de llamada estaba pasando una referencia a un objeto que ya no existía y, por lo tanto, estaba llamando a __pthread_mutex_lock en la memoria basura.
Tenga en cuenta que estaba usando std::mutex de C++ 11 y std::lock_guard<std::mutex> , pero, como estaba en Linux, el problema era exactamente el mismo.
Sólido como una roca durante 4 días seguidos. Estoy declarando la victoria en este caso. La respuesta es "error de usuario estúpido" (ver comentarios arriba). Un mutex solo debe ser desbloqueado por el subproceso que lo bloqueó. Gracias por aguantarme.
Me enfrenté al mismo problema y Google me envió aquí. El problema con mi programa era que en algunas situaciones no estaba inicializando el mutex antes de bloquearlo.
Aunque la declaración en la respuesta aceptada es legítima, creo que no es la causa de esta afirmación fallida. Porque el error se informa en pthread_mutex_lock (y no desbloquear).
Además, como siempre, es más probable que el error esté en el código fuente de los programadores y no en el compilador.