Free (NULL) ;

**ilyes_dev** · 02/02/2010, 11h26

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

Free(NULL);

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

merci

**jeroman** · 02/02/2010, 11h44

"Free", avec ou sans majuscule ?

Sans majuscule :

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.

**Jenna** · 02/02/2010, 11h50

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.

**Médinoc** · 02/02/2010, 11h51

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).

**Mac LAK** · 02/02/2010, 13h37

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.

**Médinoc** · 02/02/2010, 13h41

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

**Mac LAK** · 02/02/2010, 13h46

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...

**souviron34** · 02/02/2010, 14h02

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 ....

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 )"...

**ilyes_dev** · 02/02/2010, 14h32

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

free(NULL);

**Médinoc** · 02/02/2010, 14h46

Donc, un vrai free() en minuscules?

**souviron34** · 02/02/2010, 15h01

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...

**Mac LAK** · 02/02/2010, 16h39

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...

**Médinoc** · 02/02/2010, 17h12

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...

**Mac LAK** · 02/02/2010, 17h57

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...

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...

**LittleWhite** · 03/02/2010, 01h14

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

.
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)

**souviron34** · 03/02/2010, 02h13

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...

**Mac LAK** · 03/02/2010, 09h59

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).

**Médinoc** · 03/02/2010, 10h46

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Et ça aussi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**Mac LAK** · 03/02/2010, 12h40

Envoyé par Médinoc

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**LittleWhite** · 03/02/2010, 21h59

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

( 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à.

Free (NULL) ;

C

Discussions similaires

Partager

Partager