TLDR:Stellen Sie sicher, dass Sie keinen Mutex sperren, der zerstört / nicht initialisiert wurde.
Obwohl das OP seine Antwort hat, dachte ich, ich würde mein Problem teilen, falls jemand anderes das gleiche Problem hat wie ich.
Beachten Sie, dass sich die Assertion in __pthread_mutex_lock befindet und nicht im Unlock. Dies deutet für mich darauf hin, dass die meisten anderen Personen, die dieses Problem haben, einen Mutex nicht in einem anderen Thread als dem entsperren, der ihn gesperrt hat. Sie sperren nur einen zerstörten Mutex.
Für mich hatte ich eine Klasse (nennen wir es Foo ), die eine statische Callback-Funktion bei einer anderen Klasse registriert hat (nennen wir sie Bar ). Dem Rückruf wurde eine Referenz auf Foo übergeben und würde gelegentlich einen Mutex sperren/entsperren, der ein Mitglied von Foo war .
Dieses Problem trat nach Foo auf Instanz wurde zerstört, während die Bar -Instanz verwendete immer noch den Callback. Dem Callback wurde ein Verweis auf ein Objekt übergeben, das nicht mehr existierte und daher __pthread_mutex_lock auf Garbage Memory aufrief.
Beachten Sie, dass ich std::mutex von C++11 verwendet habe und std::lock_guard<std::mutex> , aber da ich unter Linux war, war das Problem genau dasselbe.
Rock solid für 4 Tage am Stück. Ich erkläre hier den Sieg. Die Antwort ist "dummer Benutzerfehler" (siehe Kommentare oben). Ein Mutex sollte nur von dem Thread entsperrt werden, der ihn gesperrt hat. Danke, dass du mich ertragen hast.
Ich stand vor dem gleichen Problem und Google hat mich hierher geschickt. Das Problem mit meinem Programm war, dass ich in einigen Situationen den Mutex nicht initialisierte, bevor ich ihn sperrte.
Obwohl die Aussage in der akzeptierten Antwort legitim ist, denke ich, dass sie nicht die Ursache für diese fehlgeschlagene Behauptung ist. Weil der Fehler auf pthread_mutex_lock gemeldet wird (und nicht entsperren).
Außerdem ist es wie immer wahrscheinlicher, dass der Fehler eher im Quellcode des Programmierers als im Compiler liegt.