Optimisation dans gcc -> erreur de segmentation

Bonjour à toutes et tous,

J'ai une colle à vous poser : je suis sur linux, mon code compile correctement sans et avec optimisation. Par contre, avec optimisation j'ai une erreur de segmentation quand je veux affecter une valeur à une variable de type pile. Une amie Windowsienne qui bosse sur le même projet peut optimiser son code (option dans Code::Blocks) sans erreur de segmentation...

La structure en question :

Code:

---

1 2 3 4 5 6 7

typedef struct step_str { ushort content; int i; int j; struct step_str *previous; }step;

---

Le bout de code qui pose apparemment problème :

Code:

---

1 2 3

... step pr={grid[i][j],i,j}; ...

---

Chose étonnante, quoi que je mette à la place de grid[i][j] j'ai un problème. Deuxième chose étonnante, c'est que même si je créé la variable et affecte les valeurs une par une ensuite j'ai ce problème...

Pourquoi avec optimisation mon programme plante ? Pourquoi pas sans optimisation ? 8O

Merci de me filer des idées, j'en suis à court.

Citation:

---

Envoyé par nuwanda03

Le bout de code qui pose apparemment problème :

Code:

---

1 2 3

... step pr={grid[i][j],i,j}; ...

---

---

Quand tu fais ceci, tu n'initialises que trois membres : « content », « i » et « j ». Le pointeur « previous », lui, reste indéterminé (ou mis à zéro par le jeu des initialisations).

D'autre part, en procédant de cette façon, tu déclares une variable locale, qui disparaîtra donc à la fin du bloc courant. C'est très bien comme ça mais si tu affectes son adresse mémoire au champ « previous » d'une autre instance de « step », ou de quoi que ce soit d'autre, alors cette référence deviendra caduque dès la fin de ton bloc puisque l'objet pointé aura cessé d'exister.

Citation:

---

Pourquoi avec optimisation mon programme plante ? Pourquoi pas sans optimisation ? 8O Merci de me filer des idées, j'en suis à court.

---

Parce qu'il s'agit d'un bug intermittent qui « tombe en marche ». Tant que tu restes à peu près dans un segment de mémoire qui t'est alloué, ton programme ne déclenche aucune segfault même si tu écrases joyeusement tout ce qui est autour de toi. Dès que tu en sors, par contre…

Tout d'abord, merci pour la réponse !

Ensuite, voilà un bout de code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

step* push(step **s, step p) { step *temp=malloc(sizeof(step)); if (!temp) exit(1); temp->content=p.content; temp->i=p.i; temp->j=p.j; temp->previous=*s; *s=temp; return *s; }   step* pop(step **s) { if (*s) { step *t=*s; *s=(*s)->previous; free(t); } return *s; }

---

Donc step pr={grid[i][j],i,j}; ne pose pas de problème puisque je copie son contenu dans une autre variable nommée stack , et je me moque donc royalement de la valeur de previous. Ça a été implémenté comme ça, ce n'est peut-être pas très judicieux, et je vais d'ailleurs essayer de changer ça. Mais ça veut aussi dire que le problème ne vient pas de là.

Citation:

---

Parce qu'il s'agit d'un bug intermittent qui « tombe en marche ».

---

J'ai du mal à comprendre... Que vient faire l'optimisation là dedans ?

Citation:

---

Envoyé par nuwanda03

Donc step pr={grid[i][j],i,j}; ne pose pas de problème puisque je copie son contenu dans une autre variable nommée stack , et je me moque donc royalement de la valeur de previous. Ça a été implémenté comme ça, ce n'est peut-être pas très judicieux, et je vais d'ailleurs essayer de changer ça. Mais ça veut aussi dire que le problème ne vient pas de là.

---

Merci pour le code mais le problème ne semble pas venir de cette partie. Il faudrait qu'on voie le reste.

Pour « previous », tu fais une liste chaînée : même si tu remplaces immédiatement ce champ par l'adresse du maillon précédent, il reste que cette chaîne possédera toujours un premier maillon qui, lui, ne référencera rien d'autre. Et si « previous » n'a pas été proprement initialisé, il n'y a aucun moyen de détecter l'extrémité de la chaîne.

Est-ce que ça change quelque chose si tu écris « step pr={grid[i][j],i,j,NULL}; » ?

Citation:

---

J'ai du mal à comprendre... Que vient faire l'optimisation là dedans ?

---

Par définition, un code optimisé est différent du code original et donc, les effets de bords peuvent s'en trouver modifiés eux-aussi si tu as des cas de figures indéfinis dans ton code.

Il est tout-à-fait possible, par exemple, que dans le cas normal, « previous » soit implicitement mis à zéro, ce qui est interprété ensuite comme un « NULL » par le reste de ton code mais qu'en mode optimisé, le compilateur s'épargne la peine de renseigner ce champ s'il s'aperçoit que tu ne l'utilises jamais, en tout cas pas dans le bloc où tu instancies ta structure.

La variable stack est déclarée dans le main :

Code:

---

1 2	step* stack=NULL; game(gridFilled,gridUser,mask,sizeGrid,stack);

---

Puisque stack est égale à NULL, ma fin de pile est bien délimitée, non ? Ensuite je passe ma variable dans la fonction game(), et un petit push(&stack,pr); me permet de rajouter le contenu de pr à ma pile.

Et step pr={grid[i][j],i,j,NULL}; ne donne pas mieux. De toute façon je ne récupère pas previous, donc peu importe sa valeur.

PS : je confirme que sur Windows 32 et 64 bits ça fonctionne avec optimisation (sur Code::Blocks à chaque fois). Apparemment gcc est en version 4.7.1 sur Windows, et 4.7.2 sur ma Debian.

Je peux voir avec gdb que certaines de mes variables sont <optimized out>. Et mes erreurs de segmentation semblent venir de l'accès à ma grille a cause de ces variables dont je ne peux pas connaître la valeur.

SetBit(grid[row][column], bit); est maintenant la source du problème. Ici row=0, colum et bit sont <optimized out>...

Erreur décelée : je récupérais l'adresse d'une variable locale dont la mémoire était désallouée avant que je ne fasse mon push()... Sans optimisation, peut-être que la mémoire était désallouée plus tard (ou bien le compilateur corrigeait mon erreur ?), mais avec c'était l'erreur de segmentation.

Merci bien Obsidian, mine de rien tu m'as fait cherché dans la bonne direction.

Citation:

---

Envoyé par nuwanda03

Erreur décelée : je récupérais l'adresse d'une variable locale dont la mémoire était désallouée avant que je ne fasse mon push()... Sans optimisation, peut-être que la mémoire était désallouée plus tard (ou bien le compilateur corrigeait mon erreur ?), mais avec c'était l'erreur de segmentation.

---

En fait, c'est surtout dû au fait que le système t'alloue de la mémoire par pages assez grandes et que malloc() les gère ensuite au mieux. Si tu accèdes à une variable désallouée mais qui se trouvait au sein d'une page qui est toujours à toi, alors le système ne déclenchera pas de segfault.

Citation:

---

Merci bien Obsidian, mine de rien tu m'as fait cherché dans la bonne direction.

---

Merci à toi d'avoir d'être venu marquer le sujet comme résolu.
Bon courage pour la suite.