Bonjour,
Mon program me renvoie une segmentation fault lors de l execution des lignes suivantes:  
 

 
L'ouverture de ficher se fait bien. J ai un pointeur p_stat non null et donc je ne rentre pas dans la boucle if, mais par contre lorsque la ligne avec le fprintf est execute ca crash    
J utilise deja les meme lignes de code sous windows et tout marche bien, par contre sous cygwin ca plante... est ce que quelqu'un aurait une idee? J ai essaye de changer le "wt" en "wb" dans le fopen (car le "wt" n'est pas dans mon man de cygwin) mais ca ne change rien.
 
Merci d avance

soit !, soit == NULL, mais pas 0. que dit perror ?

"wt", ça n'existe pas. C'est "w" pour les fichiers textes.
 
Poste le code complet, mais réduit au minimum qui montre le défaut.

J etais un peu etonne par le "wt" mais pas sure, bon je l ai change par "w" seulement et voici le code reduit au minimum:
 

 
Effectivement le "==0" et le "wt" n etaient pas top! Merci deja pour ces corrections. Je continue a chercher d ou vient mon erreur, mais toujours pas de solution pour le moment. J ai quand meme l impression que mon fopen renvoie un pointeur p_stat un peu bizarre (les valeurs des champs du pointeur comme flags sont pas a zeros) mais je ne suis pas sure que ce soit anormal. J ai essaye de trouver a quoi un pointer FILE etait cense ressembler sous google, mais j ai pas vraiment trouve ce que je cherchais.

manque pas un bout ?

 
Desole c est edite maintenant... petit probleme de frappe la premiere fois  

Elle fait quoi ta fonction error() ?
 
errortext, c'est une variable globale ?  
 
 
Et "code minimum", c'est "code minimum qui compile et fonctionne pour montrer l'erreur"  

Pourquoi tu fais un  snprintf avec une chaîne constante. Tu peux pas faire  directement
error( "Error open file stat.dat", 500);  
?  (c'est quoi ce 500 d'ailleurs ?)
 
Pour ton erreur, je parierais que ce n'est pas la ligne du  fprintf qui est en cause, mais qu'à un moment ou à un autre tu fais une bêtise et tu écris dans la pile ou un truc dans le genre....

Gaahhh. Il faut faire quoi pour avoir la version qui compile ?

Ce code

produit un fichier stat.dat comme ceci :

Pour moi, pas de problèmes...

 
Moi je parie pour ouverture qui rate et la fonction error() qui permet de continuer sur les fprintf().

 
apparement non...

Je sais que ca fonctionne si j ecris une fonction basique et donc que mon probleme doit venir d autre part. La ou je ne comprends pas c est que j ai le meme code sous windows et ca marche alors que sous cygwin ca coince.
 
en ce qui concerne le probleme de error qui continue sur fprintf, je ne pense pas que ce soir possible car j' ai fait du pas a pas avec gdb et je ne rentre pas dans le test "if" contenant la fonction error().

Il y a autre chose ailleurs. Il faut réduire le code jusqu'à ce que l'erreur disparaisse. Evidemment, c'est beaucoup plus facile quand le code est 'modulaire'... Il est alors facile d'en déduire le code fautif.
 
Je sens bien un débordement de chaine...
 

j'exige la backtrace

Desole de ne pas fournir un code executable qui reproduit l erreur, mais je n arrive pas a produire un code minimum qui reproduit l erreur assez petit pour etre mis ici! J'ai par contre trouve une ligne qui, lorsqu elle est enleve resouds mon segfault. J'ai:
 

 
Je ne comprends pas comment mon free peut influencer mon pointeur de fichier dans report!
 
Pour repondre a Taz: j aimerais bien fournir un backtrace, mais je suis sous cygwin et je n obtient qu un stack dump et gdb n arrive pas a l ouvrir. Je ne sais pas comment obtenir un core dump sous cygwin...

Outch. Comportement aléatoire sur un truc qui n'a rien à voir == gestion de la mémoire foireuse quelque part.
 
Si en plus ça "se résoud" (aléatoirement, donc) en retirant un free(), tu n'as plus qu'à inspecter tous tes malloc(), utilisation des blocs alloués, et free() qui vont avec.
 
Amuse-toi bien si le programme est un peu alambiqué, c'est l'une des pire erreur possible (quoique avec un truc genre Purify ça se trouve vite )

... Merci pour le message d encouragement ... et oui le porgramme est "un peu" alambique! En plus la pluspart du code n a pas ete ecrit par moi meme Je vais aller faire un tour du cote de Purify.

gcc -g machin.c -o machin.exe
gdb ./machin.exe
> bt full

 
Lorsque je fais ca gdb repond "No Stack" si le programme n est pas en train de tourner (i.e. je n ai pas attache le processus correspondant) ou me renvoie seulement quelques lignes d information sur mon main() si le processus a ete attache.

Des globales ? Question modularité, t'es mal barré...

C'est un bête comportement indéfini. Par exemple, libération d'un bloc déjà libéré, ou d'une adresse invalide (la valeur du pointeur a changé, var1++ etc.)
 

oops
 
> run
> bt full

Hors sujet : moi j'aime bien les globales. Faut arreter de crasher systematiquement sur les globales. Si un projet et bien modularise, je ne vois aucun probleme a avoir des globales "static" (les vraies globales pas static, c'est autre chose). Ca peut rendre le code plus simple et plus performant. Comme les goto. Ceux qui ne veulent pas de globales static, c'est ceux qui ont des fichiers de 10000 lignes. Ceux qui crachent sur les goto, c'est ceux qui ont des fonctions de 1000 lignes. Le probleme est ailleurs.

Ah mais les globales, c'est utile. Mais dans des cas précis, et ça s'utilise avec parcimonie.  
 
Par contre les pointeurs en variables globales, là, ça me fait peur en général.
Bon, faut dire que j'ai été traumatisé par un logiciel qui tournait dans une banque (j'vous raconte pas le prix de la license), y avait quelques Mo de fichiers sources, et quasi tout était en variablse globales, modifiées n'importe où mais pas n'importe comment. La moindre modif entrainait des effets de bords monstrueux.  
Je me voyais bon pour la camisole.

Le problème est que ça rend le code non instanciable et non réentrant... Au niveau applicatif, ca peut être acceptable, mais dans une optique de réutilisation où quasiment 'tout est bibliothèque' (pour paraphraser le fameux 'Under Unix, all is file'), ça ne marche plus. Une fois que du code est écrit avec des globales, pour le rendre éligible à la mise en bibliothèque, il faut y repasser du temps, de la validation etc. Pour moi, c'est simple, tout est bibliothèque et donc instanciable. Pas de globales.
 
Reste le problème des performances. Si effectivement, après profiling sérieux et optimisation des algorithmes, il reste un goulot d'étranglement du à une ou deux indirections de plus, pourquoi pas une solution 'jetable' avec une globale, mais il fa valloir argumenter sérieusement pour en arriver là!