Fermeture de fichier après utilisation zip.

Bonjour

J'aurais aimé faire mieux (voir http://www.developpez.net/forums/d11...copie-fichier/ ), mais encore faudrait-il que ce que je fais déjà marche correctement !

Voici mon code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

fichier=enregistre_tmp_xml(ooo); tmp1=chemin_exe(); sprintf(affichage,"%s%cLibO%cfeuille.zip",tmp1,SEPARATEUR,SEPARATEUR); sprintf(aff,"%s%c%s.odt",((char **)param)[CHEMIN],SEPARATEUR,((char **)param)[NOM]); copie_fichier(aff,affichage); f_zip=zip_open(aff,ZIP_CREATE,NULL); /* lignes (1) */ n_zip=zip_source_filep(f_zip,fichier,0,0); /* récupération du fichier sous forme FILE * sans avoir à le copier sur le disque */ /* lignes (1) */ zip_replace(f_zip,zip_name_locate(f_zip,"content.xml",ZIP_FL_NOCASE) ,n_zip); /* on l'injecte dans l'archive en lui donnant un nom */ /* lignes (1) */ zip_close(f_zip); /* on ferme l'archive */ /* lignes (1) */ free(tmp1); fclose(fichier);

---

La première ligne récupère un file * ouvert avec "FILE * sortie=tmpfile();"
Lors de la fermeture de ce fichier (dernière ligne), j'ai un plantage du programme :

Code:

---

1 2 3 4 5

*** glibc detected *** ./perso: double free or corruption (!prev): 0x0000000001024100 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x78a96)[0x7f826a132a96] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f826a136d7c] /lib/x86_64-linux-gnu/libc.so.6(fclose+0x155)[0x7f826a122715]

---

Ce que je ne comprends pas, c'est que si je commente les 4 lignes marquées en fin avec /* lignes (1) */, je n'ai plus ce plantage :(

Le problème est encore simplifiable en remplaçant la première ligne par "fichier=tmpfile(); //enregistre_tmp_xml(ooo);", ça plante encore !

Le plantage a bien lieu lors du "fclose(fichier)" et tout ce qui a été fait avant a bien été fait (fichier de sortie vérifié).

J'avoue ne pas comprendre la raison de ce plantage testé sous ubuntu 11.10 et mageia 2.

Je n'ai jamais utilisé la libzip, cependant, d'après le source ici :
https://bitbucket.org/glorpen/curse/...source_filep.c

libzip peut fermer le fichier, si tu as appelé zip_source_filep (en tt cas, c'est comme ça que j'en comprends le source). Le manuel semble ne rien dire à ce sujet.

Du coup, faire un fclose dessus revient à demander à la librairie standard de fermer un fichier déjà fermé, si je ne m'abuse.

est-ce que ce que je dis parait avoir un sens ou bien j'ai rien compris ?

Je ne vois pas où mon fichier est fermé dans ce code source ! Je pense bien à quelque chose comme ça, mais je ne vois pas pourquoi la fonction ferrait ça et je trouve même que ce serait anormal !

Il y a bien la ligne 238, mais comment je sais si ça passe par là :

Code:

---

1 2 3 4 5 6

case ZIP_SOURCE_FREE: free(z->fname); if (z->closep && z->f) fclose(z->f); free(z); return 0;

---

La logique derrière ça je la connais pas, mais il stocke bien ton pointeur de fichier passé par zip_source_filep, et sous certaines conditions (que je ne maitrise pas), il le ferme.
Tu dois pouvoir prouver ou infirmer ma théorie si tu trouves une façon de voir combien de fichiers sont ouverts par ton processus à un instant T.
Ou en utilisant je ne sais plus quel outil génial qui te permet de tracer les appels systèmes.

Hello,

Tu utilises un grand nombre de fonctions dont on ne dispose pas du code source. C'est donc difficile de t'aider en l'état mais, à vue de nez, tu commences par allouer « tmpl » avec la fonction chemin_exe() sans vérifier si l'appel a réussi ou pas. Tu considères que la valeur de retour est forcément valide. Rien que ça, ça suffit à rendre ton programme incorrect sauf si tu peux garantir que chemin_exe() est dotée de dispositifs permettant de rattrapper les éventuelles erreurs ou mettre fin au programme (sauvagement, mais bon).

Malgré cela, si le programme cesse de planter lorsque tu enlèves les lignes que tu as marquées, c'est qu'il est probable que les fonctions qui y sont appelées fassent un dépassement de tableau et aillent corrompre la pile. Les valeurs dans tes variables ne sont alors plus du tout valides.

Les fonctions que j'utilise au début marchent bien :

Code:

---

1 2 3 4

fichier=enregistre_tmp_xml(ooo); tmp1=chemin_exe(); [...] copie_fichier(aff,affichage);

---

La suite me le montre sans problème.
Il est vrai qu'elles sont sensées marcher correctement, sinon, le programme plante. Dans le cas présent, je sais que ces fonctions marchent sans problème.

Le problème de la corruption de mes variables après l'appel de la fonction n'est pas viable, car le programme plante pendant l'appel de la fonction fclose(fichier); , pas après. Tu me conseillerais de mettre plus tôt (3 lignes) afin de mieux tester ?

Pour être encore plus radical, j'ai deux fois à peu près le même mode opératoire dans deux parties du programme, et les deux fois, j'ai le même problème que j'ai résolu de la même façon.

Sinon, si tu veux mon code source, il est disponible sur http://troumad.org/Mes_regles/perso3.zip (17000 lignes).

à vue de nez, moi ça me semblerait être un problème soit de variable servant à un double usage (par exemple un pointeur réalloué ou modifé dans une des fonctions appelalntes) soit une variable allouée par la biblothèque, et libérable uniquement par la biblothèque mais que tu libérrais de l'extérieur (un peu comme les struct *tm ou la chaîne du strtok)

Il est quand même curieux que les lignes qui font planter consistent en "ouvrir" et "replace" :aie:

Es-tu sûr que le replace ne ferme pas le fichier ? Auquel cas le close du zip avant replace ne correspond à rien ?

Pour ma part, je commencerais par tenter soit juste d'enlever le close du zip, soit de modifier le replace et le remplacer par juste un copy.

les lignes de mon précédent messages ne font absolument pas planter ! Ce sont juste les trois fonctions persos de l'ensemble.


La ligne qui fait planter est

Code:

---

fclose(fichier);

---

Si je la commente, le programme marche à merveille. Mais, je n'aime pas commenter une ligne sans comprendre.
Ceci me gène d'autant plus qu'avant j'avais un code presque équivalant, sauf que je passais par un fichier réel, pas un virtuel et qu'il fallait bien le libérer.