Erreur d’assertion de mutex Pthread

Je rencontre l’erreur suivante à des moments imprévisibles dans une application de communication (arm) Linux:

pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. 

Google renvoie de nombreuses références à cette erreur, mais peu d’informations qui semblent pertinentes pour ma situation. Je me demandais si quelqu’un pouvait me donner des idées sur la façon de résoudre cette erreur. Est-ce que quelqu’un connaît une cause commune pour cette affirmation?

Merci d’avance.

Rock solide pendant 4 jours d’affilée. Je déclare la victoire sur celui-ci. La réponse est “erreur d’utilisateur stupide” (voir les commentaires ci-dessus). Un mutex ne devrait être déverrouillé que par le thread qui l’a verrouillé. Merci de vous occuper de moi.

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 l’énoncé 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 non pas déverrouillée).

En outre, comme toujours, il est plus probable que l’erreur se trouve dans le code source du programmeur plutôt que dans le compilateur.

Le peu de googling que j’ai fait blâme souvent cela sur une mauvaise optimisation du compilateur. Une sommation décente est ici . Il pourrait être utile de regarder la sortie de l’assemblage pour voir si gcc produit le bon code.

Soit ça, soit vous arrivez à piétiner la mémoire utilisée par la bibliothèque pthread … ces types de problèmes sont plutôt difficiles à trouver.

TLDR: Assurez-vous de ne pas verrouiller un mutex détruit / non initialisé.

Bien que le PO 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 se trouve dans __pthread_mutex_lock et non dans le délocking. Ceci, 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 ne font que verrouiller un mutex qui a été détruit.

Pour moi, j’avais une classe (appelons-la Foo ) qui a enregistré une fonction de rappel statique avec une autre classe (appelons-la Bar ). Le rappel était passé une référence à Foo et verrouillerait / déverrouillerait de temps en temps un mutex qui était un membre de Foo .

Ce problème s’est produit après la destruction de l’instance Foo alors que l’instance Bar utilisait toujours le rappel. Le rappel était passé une référence à un object qui n’existait plus et appelait donc __pthread_mutex_lock dans la mémoire de mémoire.

Notez que j’utilisais std::mutex et std::lock_guard C ++ 11, mais comme j’étais sous Linux, le problème était exactement le même.

J’avais le même problème

Dans mon cas, à l’intérieur du thread, je connectais vertica db avec odbc en ajoutant le paramètre suivant à /etc/odbcinst.ini résolu mon problème. ne pas obtenir l’exception jusqu’ici.

 [ODBC] Threading = 1 

crédits à: hynek

Ajout de Threading = 0 dans le fichier /etc/odbcinst.ini corrige ce problème