erreur de segmentation sur pthread_mutex_lock

J'obtiens une erreur de segmentation quand j'essaie de faire

pthread_mutex_lock(&_mutex).

Ce qui est vraiment bizarre, je ne suis pas sûr de ce que peut être en cause. J'ai initialisé _mutex dans le constructeur avec

pthread_mutex_init(&_mutex,NULL).

tout ce que je peux faire?

afficher plus de code, s'il vous plaît. Il est très probable que le problème est quelque chose de complètement différent et juste surfaces dans votre pthread_mutex_lock appel.
Il est imposable pour aider avec les informations que vous avez fournies. Vous n'obtiendrez rien de plus que des suppositions éclairées.
J'espérais une supposition, quelque chose le long des lignes de "vous avez besoin d'appeler un mondial de l'initialisation de la fonction dans le main()". Il s'avère que c'est juste quelque chose de stupide. Eh bien, seg fault, qu'attendez-vous?

OriginalL'auteur Nefzen | 2009-06-02

  1. 5

    résolu, et je suis très ennuyé de cette.
    J'ai voulu envoyer un Producteur* comme argument à la fonction Pthread fonctionne, j'ai donc utilisé &(*iter), où iter est un itérateur qui s'exécute sur un des producteurs de vecteur.

    je ne savais avis il a été (à juste titre) un vector< Producteur* >, ce qui signifie que j'ai été l'envoi de Producteur* * qui a produit des résultats inattendus. grrrrr. Évidemment, je n'avais pas remarqué ce parce que les Pthreads est dans le plus pur C et à cet effet utilise void* comme c'est seul moyen d'accepter n'importe quel type d'arguments.

    Je pensais que j'allais avoir à passer des heures à essayer de comprendre pourquoi j'ai été faire une erreur de segmentation sur un mutex lock, mais c'était le premier post que j'ai trouvé et s'avère m'est arrivé d'être en train de faire exactement la même chose que vous!

    OriginalL'auteur Nefzen

  2. 2

    Joindre un débogueur et trouver exactement quelle est la cause de l'erreur de segmentation. Il est possible que certaines pointeur pointant simplement dans un caractère aléatoire ou non initialisée zone.

    Également exécuter valgrind's memcheck et voir ce que ça dit.

    modifier

    En réponse aux commentaires ci-dessous, l'utilisation de la pthread API de son incorrecte quelque part. J'ai recommandé "PThread la Programmation" par O'Reilly comme une référence. C'est ce qui me va 🙂 j'ai deviné ce parce que l'utilisation de l'API est le déplacement d'un pointeur interne de la pthread_mutex_t struct dans un endroit dangereux. Cela ne devrait pas arriver avec une bonne utilisation de l'API.

    Je voudrais bien, mais l'Éclipse a choisi de ne pas coopérer et de débogage ne fonctionne pas pour le moment 😡
    Vous allez avoir à le faire. Il est peu probable d'être un bug dans le pthread API ... de façon à ce que les feuilles de votre code :S 🙂
    Je suppose que. eh bien, j'ai réussi à résoudre le bogue d'Eclipse, donc je suis content, d'autant que je peux l'être compte tenu de la débogage j'ai à faire maintenant.
    Aussi, vous pouvez lancer 'gdb' et 'valgrind --leak-check=full myprog" à partir de la ligne de commande. Eclipse n'est pas nécessaire pour cela.
    🙂 Bonne chance avec votre débogage 🙂 Si vous êtes nouveau, le débogage est plus rapide

    OriginalL'auteur Aiden Bell