Segmentation fault, trop de thread fils

Citation:

---

Envoyé par publicStaticVoidMain

Normalement, dans la boucle, avec pthread_create il est très conseillé de ne passer directement l'adresse de i qui peut etre modifié par la thread principale avant/pendant la création de la nouvelle thread.
Donc, l'idéal serait de faire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

int *ptr;   for(i=0; i < NB_THREAD; i++){ ptr = (int *) malloc(sizeof(i)); pthread_create(&L[nb_lecteurs], NULL, lecteur, (void*)ptr);     //blablabla   }

---

---

idéalement on ferait un tableau de NB_THREAD int.

Citation:

---

Envoyé par publicStaticVoidMain

Concernant la portabilité, on pourrait programmer suivant la norme POSIX, non? On s'en fout un peu de la façon dont NULL et compagnie est implémentée du moment que le système respecte cette norme. (corrigez moi si je dis une connerie)

---

Et tu penses qu'on fait quoi? pthread_create () est une fonction POSIX, et POSIX est aligné sur le standard C99.

Bon,
Je reconnais que le premier post cité est erroné :oops:, j'avais mal compris.
Chaque machine à sa représentation du pointeur null pour chaque type, qui n'est pas forcément zéro.
C'est le compilateur qui fait la traduction quand il reconnaît être dans un contexte de pointeur (avec la valeur 0) ou quand cela est explicité (ex : void*).

De plus on ne sait pas ce qui arrive quand on caste d'un entier vers un pointeur et vice-versa (ce qui est fait ici lorsque l'on passe en paramètre i) et on risque de ne pas "retomber nos pattes" (ici retrouver la valeur de i).

Cela marche apparemment pour gcc/Linux/x86, mais il peut en être autrement.

Cela dit, le problème dans son code venait de la gestion de ses verrous.

http://www.lysator.liu.se/c/c-faq/c-1.html