Abort sur pthread_mutex_lock

Salut,

J'ai une petite application serveur qui utilise des pthread.

De temps en temps, lors d'un pthread_mutex_lock, j'ai l'erreur suivante qui se produit :
Abort pthread_mutex_lock.c:108: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

Je n'arrive pas à voir ce qui peut causer ça (ça semble assez aléatoire) et mes recherches ne m'ont pas permis d'identifier le problème.

Apparemment le système sur lequel le programme tourne a une importance donc j'ai un debian etch 64 bits avec dual core, je compile mon projet avec l'option -O2.

Est-ce que quelqu'un sait d'où peut venir ce problème ?

Merci !

Tu dois probablement verrouiller un mutex que tu as déjà verrouillé, et ton mutex ne doit pas être récursif.

Salut, merci pour ta réponse.

J'ai fait des essais en lockant plusieurs fois le même mutex sur un même thread et l'application reste bloquée lorsqu'elle tente de locker une deuxième fois le mutex. Par contre, je n'ai aucun Abort.

Cela confirme que le mutex n'est pas récursif. Cela réclame donc une attention particulière sur son utilisation.

J'avoue que je comprends pas trop en quoi ça pose un problème.

Ca me semble normal qu'un mutex déjà verrouillé et qui est de nouveau verrouillé par le même thread entraîne un deadlock.

Mais si c'est une des causes possibles de mon erreur, je vais essayer avec des mutex recursifs et je vous tiendrais au courant.

Citation:

---

Envoyé par BestFF

Ca me semble normal qu'un mutex déjà verrouillé et qui est de nouveau verrouillé par le même thread entraîne un deadlock.

---

Pas à moi. Ça doit soit lever une erreur (comme ici, l'assertion), soit l'accepter immédiatement en comptant les locks.

Le danger inhérent aux mutexes récursifs est le risque de deadlock quand un thread est supposé rendre le mutex et attendre qu'un autre ait modifié l'objet: Si ledit thread a gardé un lock, le second ne pourra jamais modifier l'objet.

Ah oui vu comme ça ^^;

Donc dans mon cas où je n'ai pas prévu qu'un mutex soit acquis plusieurs fois, je devrais plutôt utiliser les mutex ERRORCHECK pour qu'il me lève une erreur à l'endroit où le mutex n'aurait pas du être acquis ?