Comportement étrange avec free.

Bonjour,

Je poste car j'ai un soucis de free.

Code:

---

1 2 3 4 5

mydebug("prec->fields[i].data.value.a_string=[%s]\n", prec->fields[i].data.value.a_string); mydebug("strlen=[%d]\n", strlen(prec->fields[i].data.value.a_string)); free(prec->fields[i].data.value.a_string); mydebug("fin\n");

---

mydebug est une fonction qui log avec un flush.
Le debug affiche

Code:

---

1 2	prec->fields[i].data.value.a_string=[31313200 ] strlen=[11]

---

Mais pas "fin", et pour cause, il y a eu un seg fault...
Mais dans la mesure ou on peut afficher le contenu de la variable et calculer sa taille avec un strlen, le fait qu'il ne puisse pas faire de free me semble completement inconpréhensible. Bref, si quelqu'un a la moindre piste, je suis prenneur !

A noter que ce code se trouve dans une boucle ou i est incrémenté de 1 à 140, et je n'ai le problème que pour un seul cas (le 119)...

Merci d'avance ;-)

Bonjour,

pour commencer comme trace je proposerai ca histoire d etre bien sur d ou on en est :

Code:

---

1 2 3 4 5

mydebug("prec->fields[%d].data.value.a_string=[%s]\n", i, prec->fields[i].data.value.a_string); mydebug("strlen=[%d]\n", strlen(prec->fields[i].data.value.a_string)); free(prec->fields[i].data.value.a_string); mydebug("fin\n");

---

mais pourrais tu nous montrer comment est allouée et remplie cette structure.

Citation:

---

Envoyé par Rakken

Bonjour,

…

Mais dans la mesure ou on peut afficher le contenu de la variable et calculer sa taille avec un strlen, le fait qu'il ne puisse pas faire de free me semble completement inconpréhensible. Bref, si quelqu'un a la moindre piste, je suis prenneur !

A noter que ce code se trouve dans une boucle ou i est incrémenté de 1 à 140, et je n'ai le problème que pour un seul cas (le 119)...

Merci d'avance ;-)

---

si strlen ne se plante pas celà signifie simplement que le pointeur qui lui est donné en argument correspond bien à une adresse mémoire du processus et qu'il trouve un byte '\0' avant de tomber sur une adresse mémoire non mappée…

si free se plante avec la même adresse mémoire cela peut signifier :
que cette adresse n'a pas été allouée par l'allocateur …
que les données du bloc mémoire utilisée par l'allocateur ont été corrompues par le programme… en général quelque chose du genre un strcpy, memmove, … qui déborde…

Hello,
en voyant le code que tu nous montres, il ne semble pas y avoir d'erreur. Du coup si tu es sous unix je te conseil d'utiliser des outils pour verifier tes acces memoire tel que valgrind, ca te permettra deja de voir si tu fais des lectures/ecritures qui debordes sans que tu le vois.

Sinon montre nous comment tu alloues ta structure. Une derniere chose, si tu deplace le pointeur de la string, le remet tu bien en place avant de free ? (typiquement un truc du genre : (prec->fields[i].data.value.a_string)++ )

strlen va juste te dire à quelle distance se trouve le premier '\0' depuis le pointeur que tu lui donnes. Il ne plante pas tant que l'adresse fournie est valide même si elle n'a pas été allouée par malloc! free plante: plusieurs pistes possibles:

1. Comme le dit oniric, ton pointeur d'adresse s'est déplacé entre temps,
2. la chaîne a été alloué avec une taille ne tenant pas compte du '\0'
3. la chaîne a encore plus brutalement débordée,
4. l'écrasement mémoire peut avoir eu lieu juste avant le bloc mémoire de la chaîne,
5. le pointeur n'est pas un bloc alloué dynamiquement mais un tableau de taille fixe,
6. la chaîne a déjà été libérée.

Et il y en a surement d'autre encore.

Si tu travailles sous Visual C++, tu peux installer purify (payant je crois...). Il va tester toute ta mémoire. Ce module m'a rendu bien des services !

Merci pour toutes ces réponses. Je pensais que faire un printf d'un emplacement mémoire non alloué plantait systématiquement. D'où ma surprise initiale, mais maintenant que vous le dites, c'est vrai que le C étant ce qu'il est, on peut lire un peu n'importe où dans la mémoire.
Bref, j'ai fini par trouver une solution... ca me semble étrange, mais depuis, je n'ai pas réussi à reproduire le seg fault.
En fait, après ce free qui plante, un élément de la structure globale (qui venais donc de se faire désallouer) était encore lu une derniere fois. Ce qui me provoquait des incohérences dans certaines valeurs (c'est comme ça que je m'en suis rendu compte). J'ai donc déplacé la fonction de libération de mémoire après ma dernière lecture, et depuis, plus de seg fault.
Au final, je n'ai toujours pas compris pourquoi avant ça plantait, mais ça m'a permis de trouver d'autres soucis et en résolvant ces autres soucis, désormais, tout fonctionne.
J'ai réussi à réunir théorie et pratique, ca marche, et je ne sais pas pourquoi :yaisse2: Mais résolut tout de même ;-)

Et je vais aller jeter un oeil du coté des outils que vous m'avez proposé, ca à l'air plutôt interessant.

Cette lecture devait te faire seg fault car ton dernier pointeur devait etre sur le sommet du tas (= "pile ou est reservés l'espace memoire dynamique"). du coup lorsque tu as free l'espace, le brk (le haut du tas qui monte et descend selon les allocs) a du redescendre, et toi tu as essayé de lire au dessus => SegV à 100%, c'est interdit de lire au dessus (segV : segmentation Violation).

C'etait la minute je parle en chinois :D

content que tu ai trouvé ton probleme :) l'avantage des segfault c'est que au moins on se rend compte qu'il y a probleme et on peut le trouver. Le pire c'est quand on a aucune erreur visible, mais que ca fonctionne pas :D

Citation:

---

Envoyé par Rakken

J'ai réussi à réunir théorie et pratique, ca marche, et je ne sais pas pourquoi

---

Nan ca c est la theorie :P

Citation:

---

Envoyé par albert einstein

La théorie, c'est quand on sait tout et que rien ne fonctionne.-La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.-Si la pratique et la théorie sont réunies, rien ne fonctionne et on ne sait pas pourquoi.

---

Bien vu ;-)