Free (NULL) ;

Salut,

Je suis entrain de chercher une expliquer pour le phénomène de Hung up (surtout pour les système embarqués).
pourquoi observe t'on une crash du système en exécutant une instruction

Code:

---

Free(NULL);

---

je suis juste entrain de chercher le scénario pour mieux imaginer la situation!


merci

"Free", avec ou sans majuscule ?

Sans majuscule :

Citation:

---

free() libère l'espace mémoire pointé par ptr, qui a été obtenu lors d'un appel antérieur à malloc(), calloc() ou realloc(). Si le pointeur ptr n'a pas été obtenu par l'un de ces appels, ou s'il a déjà été libéré avec free(), le comportement est indéterminé. Si ptr est NULL, aucune tentative de libération n'a lieu.

---

"Free" avec majuscule, je ne connais pas. :oops:

Citation:

---

Envoyé par jeroman

Si ptr est NULL, aucune tentative de libération n'a lieu.

---

Peut être que certaines librairies (en embarqué) ne collent pas exactement à la norme et que cela peut les crasher.

En effet, Free() avec majuscule ne fait pas partie de la bibliothèque standard, ni de POSIX.

En standard, tu as free(NULL) qui ne fait rien et fclose(NULL) qui est un comportement indéfini (en clair, un bug, plante sous Windows).

J'ai même déjà vu des librairies embarquées où les fonctions d'allocation dynamiques n'existaient tout simplement pas...

Il faut voir ce que fait ta fonction de libération, mais une chose est sûre : tester la validité du pointeur à libérer coûte un peu de code et de temps CPU. Certes, c'est très faible, mais pour certaines cibles très fortement contraintes à ce niveau, c'est déjà trop.
Donc, on vire souvent 100% des tests anti-crash pour gagner de la place en mémoire (footprint + consommation RAM), et si tu te plantes dans tes appels, c'est tant pis pour toi.

Enfin, je n'appelle pas free(NULL) "se planter dans les appels" quand c'est une garantie du standard...

Citation:

---

Envoyé par Médinoc

Enfin, je n'appelle pas free(NULL) "se planter dans les appels" quand c'est une garantie du standard...

---

Encore faut-il que ton compilateur et ta CLib soient standards, ce qui est assez fréquemment un vœu pieux avec les SDK de microcontrôleurs... :(

et pas seulement avec les biblothèques micro, comme j'ai déjà eu le loisir de le dire... ici-même..

Mais je me suis fait taper dessus .... :roll:



Encore une fois, je répète : pour faire un vrai code propre, sûr, passant partout, c'est franchement pas compliqué de rajouter un "if ( ptr != NULL )"...

okay je suis tout à fait d'accord avec vous seulement je veux comprendre pourquoi le système crash?? je cherche plutôt une explication logique du phénomène.

et concernant la fonction c

Code:

---

free(NULL);

---

Donc, un vrai free() en minuscules?

Citation:

---

Envoyé par ilyes_dev

okay je suis tout à fait d'accord avec vous seulement je veux comprendre pourquoi le système crash?? je cherche plutôt une explication logique du phénomène.

---

tout simplement parce que le test mentionné ci-dessus n'est pas inclus dans la version de ta bibliothèque dans la fonction free...

Or , à l'intérieur, free met à jour des pointeurs et utilise des fonctions bas niveau..

La présence d'un pointeur NULL, si non testée à l'entrée, provoquera tout un tas de choses étranges, dont l'accès à une adresse non valide ou une adresse négative, par soustraction...

Ou pire : sur un microcontrôleur, tenter de marquer comme "libre" l'adresse NULL (donc, zéro) revient à tenter d'écrire dans cette zone mémoire... Qui est bien souvent le vecteur de démarrage du processeur, correspondant donc à de la belle mémoire ... ROM !! Ou Flash, mais ce n'est pas mieux à ce niveau.

Cela plante donc parce que tu tentes d'écrire dans une mémoire qui ne peut pas l'être. Comme ça peut planter parce que tu soustrais la taille de l'entête de tas, que tu boucles en fin de mémoire sur des zones non accessibles, ou que tu tapes dans des registres importants, bref des infinités de raisons.

Retiens surtout ceci : ça crashe ? Alors ne le fais pas, et blinde ton code en amont (si tu le peux), ou mieux : vérifie le bug sévère qui t'a mis un pointeur officiellement alloué à NULL sans te prévenir... ;)

Citation:

---

Envoyé par Mac LAK

ou mieux : vérifie le bug sévère qui t'a mis un pointeur officiellement alloué à NULL sans te prévenir... ;)

---

Sauf que ce n'est pas toujours un bug, et souvent tu es prévenu. Je pense notamment à des structures dont certains membres seraient optionnels. Bien sûr, rajouter le test n'est pas grand-chose, mais ça n'en est pas moins frustrant (pour moi, du moins) quand le standard dit qu'on n'est pas censé avoir besoin de le mettre...

Citation:

---

Envoyé par Médinoc

Sauf que ce n'est pas toujours un bug, et souvent tu es prévenu.

---

Ben tenter de libérer un pointeur NULL, faut qu'on m'explique où est passé le pointeur initial, pourquoi plusieurs entités peuvent le libérer sans protections, et pourquoi c'est une entité qui ne "possède" plus le bloc qui tente de le libérer... ;)
Je t'accorde que ce n'est pas toujours un bug : c'est plus souvent une erreur de conception... :mrgreen:

Citation:

---

Envoyé par Médinoc

Je pense notamment à des structures dont certains membres seraient optionnels. Bien sûr, rajouter le test n'est pas grand-chose, mais ça n'en est pas moins frustrant (pour moi, du moins) quand le standard dit qu'on n'est pas censé avoir besoin de le mettre...

---

D'un autre côté, en embarqué, on a tendance à fuir les "cas particuliers" à l'exécution, et à se taper des tonnes de cas particuliers à l'écriture par contre (notamment non respect des standards)...
Les structures avec champs optionnels ? Cela existe, dans le principe, sauf qu'en général c'est souvent alloué malgré tout (déterminisme de la consommation mémoire), et rempli de données neutralisant les actions derrière (ex : taille à zéro, chaînes vides, etc.).

Du coup, si tu dois faire des tests de ce genre, tu as des chances de perdre plus de temps machine (au final) qu'en allouant bourrinement... Ce qui n'est donc pas rentable. D'où inutilité du test (encore un poil de gain), et pas d'appel à free avec un paramètre NULL (encore du gain).

Je sais, c'est parfois une mentalité bizarre. J'ai mis longtemps à m'habituer à un principe courant qui est qu'un programme ne s'arrête pas, par exemple, ce qui fait que le code d'arrêt "propre" est superflu, coûteux et donc éliminé. Au début, ça m'a fait pas mal hurler d'arrêter un programme à coup de bouton ON/OFF... ;)

J'ai parcouru un peu en travers le sujet et je reste assez perplexe.

Le free(NULL) fonctionne très bien. Je l'utilise surement à outrance :aie:.
Mais sur les machines que j'ai utilisé, je peux cité, ces: Linux / Windows ( classique ) / WinCE6 / uITRON / Symbian (ARMV5)

uITRON est la machine la plus pénible, est pourtant, ça, ça marche.
Du coup, je voudrais bien connaitre quel est la machine avec lequel le problème arrive?
Et aussi, est on archi sur que c'est un free(NULL). Peut être que le pointeur passé n'est pas exactement à NULL. (parce que l'on n'ecrit pas free(NULL) explicitement)

cela dépend des biblios et machines..

Dans ce que j'avais cité il y a 1 an ou 2, il y avait des serveurs HP (HPUX), des machines Silicon (IRIX) , dans le milieu/fin des années 90 et par exemple Linux redhat au moins jusqu'à 7.3, c'est à dire environ 2002...

avec gcc..

et la libc locale...

Pour ce cas-ci je ne sais pas...

Citation:

---

Envoyé par LittleWhite

Mais sur les machines que j'ai utilisé, je peux cité, ces: Linux / Windows ( classique ) / WinCE6 / uITRON / Symbian (ARMV5)

---

Ce qui reste encore des plate-formes relativement classiques, à part µITRON que je n'ai jamais rencontré pour l'instant.

Pour ma part, j'ai déjà eu ce genre de problème sur des CPU 16 bits Fujitsu et Hitachi, sur d'anciens compilateurs embarqués C/C++, sous DOS/Win16, sur des machines Solaris, et sur quelques serveurs *nix de ma fac (c'était peut-être le HP-UX, d'ailleurs).

Citation:

---

Peut être que le pointeur passé n'est pas exactement à NULL. (parce que l'on n'ecrit pas free(NULL) explicitement)

---

Ah ça, par contre, ça peut tuer un programme.

Ça aussi, d'ailleurs:

Code:

---

1 2	struct uneStructure * ps = malloc( sizeof *ps ); free(&ps->un_champ_qui_nest_pas_le_premier);

---

Et ça aussi:

Code:

---

1 2	struct uneStructure * ps; /*non-initialisé*/ free(ps);

---

Citation:

---

Envoyé par Médinoc

Ah ça, par contre, ça peut tuer un programme.

---

Un double free peut faire le même effet parfois :

Code:

---

1 2 3

void* machin = malloc(100); free(machin); // OK. free(machin); // Boum, ou pas boum ? Comportement indéfini d'après la doc...

---

uITRON, c'est le nom du système. C'est pour les microprocesseur.
Le microprocesseur sur lequel on fait tourner ça vient de chez Renesas ( et leur compilo est vraiment pas gentil ( super strict )).

Et le double free ... ça fait boum très ( trop ) facilement :D ( du moins, je l'ai jamais vu ne pas faire boum )... ah si ... maintenant je me rapelle, avec gcc, il y a une option ( si c'est bien pour ce cas là ) qui dit de pas faire l'erreur ( avec le dump ) dans ce cas là.

Citation:

---

Envoyé par Mac LAK

Un double free peut faire le même effet parfois :

Code:

---

1 2 3

void* machin = malloc(100); free(machin); // OK. free(machin); // Boum, ou pas boum ? Comportement indéfini d'après la doc...

---

---

Tu peux éviter ce pb en créant ta propre macro

Code:

---

1 2 3 4 5

#define FREE(x) (free(x), (x)=NULL)   void* machin = malloc(100); FREE(machin); // OK. FREE(machin); // OK aussi.

---

Tu peux aussi éviter ce pb en faisant attention à ce que tu tapes

Code:

---

1 2 3

void* machin = malloc(100); free(machin); // OK. free(machin); // juste pour prouver à la communauté C qui me regarde d'un air désaprobateur que je suis vraiment trop con

---

:mrgreen:

Pour être franc je préfère encore le BOUM.

@Sve@r: Je pense que tout ceux qui ont répondu au sujet savent très bien comment éviter ces problèmes :).

Pour le boum... je le préfère aussi ... mais des fois, je trouve ça pénible ( quand je trouve pas d'où cela vient.

Citation:

---

Envoyé par Sve@r

Tu peux éviter ce pb en créant ta propre macro

---

Qu'il faut alors préfixer par un test "if ((x)!=NULL) : je le répète, le comportement d'un double free est indéfini quel que soit la cible, et libérer NULL peut poser des problèmes suivant les cibles. Il faut donc blinder à deux niveaux.

Après, il y a plein de (bonnes) méthodes pour libérer la mémoire proprement, que ce soit en C ou en C++ d'ailleurs. L'important, c'est surtout de retenir que ce qui est valable sur un PC est loin d'être aussi valable sur des cibles embarquées.

Si on veut faire dans la macro ... ça sera donc du genre:

Code:

---

1 2 3 4 5 6 7

#define FREE(x) \ if ( x )\ {\   free(x);\   x = NULL;\ }

---

Et hop ... rien avant, et rien après la macro :). Et nous sommes propre :)

Citation:

---

Envoyé par LittleWhite

Si on veut faire dans la macro ... ça sera donc du genre:

---

Si l'on veut être "ultime" et blinder à tous les niveaux, ça va plutôt donner :

Code:

---

#define FREE(x) do { if (x) { free(x); x = NULL; } } while (0)

---

Là, t'es blindé sur les conditions du free, et en plus sur le fait de se servir de la macro au même titre qu'une instruction... ;)
Pour protéger au niveau de l'interprétation multiple du "x", il faudrait passer par une fonction inline intermédiaire qui assurerait l'interprétation unique du paramètre, mais là, ce n'est plus de la macro "pure".

Mais bon, on digresse : je l'ai déjà dit, mais l'important, c'est de retenir qu'en embarqué, il ne faut pas présupposer que le comportement du compilateur et/ou de la CLib est identique à ce que l'on trouve sur le PC.