Discussion :

[leprofmelo]

Bonjour,
Je développe depuis peu en C et je commence tout juste à assimiler les concepts de pointeurs et gestion mémoire. Jusqu'à maintenant je n'ai pas vraiment eu de problemes avec la gestion dynamique de la mémoire. Mais là si. Je n'arrive pas à libérer de la mémoire suite à une structure de données un peu spéciale et qui doit sans doute être fausse. J'aimerai bien une petite explication clair du bug.
Voici le code. A la fin il y a 2 tests de print et j'obtiens une valeur pour test.toto[33].toto1 alors que je pensais avoir libéré la mémoire. Merci de votre aide:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
 
#include <stdio.h>
#include <stdlib.h>
 
int main(void)
{
	struct TOTO
	{
		int toto1;	
	};
 
	struct TEST
	{
		int test1;
		float test2;
		float test3[2];
		struct TOTO *toto;	
	};
 
	struct TEST test;
 
	if((test.toto = (struct TOTO*)malloc(50*sizeof(struct TOTO))) == NULL)
	{
		printf("erreur");
	}
 
	test.test1 = 1234;
	int i;
	for(i=0;i<50;i++)
	{
		test.toto[i].toto1 = i;	
	}
 
 
	printf("%d\n",test.test1);
	printf("%d\n",test.toto[33].toto1);
        //je libere la memoire de *toto, enfin je croyais
	free(test.toto);
	printf("%d\n",test.toto[33].toto1);
 
	return EXIT_SUCCESS;	
}

[diogene]

Oh! la mémoire a été libérée mais pas réutilisée pour stocker quelque chose et il reste dedans les anciennes valeurs

[leprofmelo]

Mais alors est ce que ce code est juste.......
Et pourquoi ai je acces aux valeurs alors que je pensai perdre l'adressage mémoire ?
Merci déjà de ta première réponse.

[Sve@r]

Mais alors est ce que ce code est juste.......

Non puisque tu demandes une information qui ne t'appartient plus depuis le free(). Le comportement est indéterminé (personne ne peut prévoir ce qui va se passer => tu peux aussi bien récupérer les anciennes valeurs que faire planter ton programme)

Et pourquoi ai je acces aux valeurs alors que je pensai perdre l'adressage mémoire ?

Ben pourquoi le C devrait réinitialiser inutilement cette zone et avec quelle valeur ? La zone est libre donc le prochain qui la récupère pourra y écrire ce qui lui semble important mais tant que personne n'a rien écrit la zone garde les dernières valeurs stockées...

[diogene]

Une adresse reste une adresse

Code :

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

1
2
3
        //je libere la memoire de *toto, enfin je croyais
	free(test.toto);
	printf("%d\n",test.toto[33].toto1);

Ce qui est sûr, c'est que ce printf est incorrect et que tu as la MALCHANCE qu'il ne te donne pas une valeur incohérente et que ton programme ne plante pas sur le champ : Tu accèdes à des zones mémoires qui ne t'appartiennent plus et le résultat est imprévisible.

[leprofmelo]

Merci de ta réponse sve@r, mais alors autre question ? Est ce que la mémoire reste occupée pour le system d'exploitation au point d'avoir l'impression qu'il y a une fuite mémoire ?

[diogene]

Merci de ta réponse sve@r, mais alors autre question ? Est ce que la mémoire reste occupée pour le system d'exploitation au point d'avoir l'impression qu'il y a une fuite mémoire ?

Non

[jeremy13]

Pour être propre, tu devrais écrire :

Code :

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

1
2
3
4
 
	free(test.toto);
        test.toto = NULL;
	//printf("%d\n",test.toto[33].toto1);

J'ai mis ton printf en commentaire sinon ça va planté...

[Sve@r]

Merci de ta réponse sve@r, mais alors autre question ? Est ce que la mémoire reste occupée pour le system d'exploitation au point d'avoir l'impression qu'il y a une fuite mémoire ?

Ben non puisque justement tu demandes que la mémoire soit libérée. Le système peut pas croire qu'elle est restée occupée.
En revanche, si tu oublies le free() alors certains systèmes comme Unix/Linux libèrent automatiquement la mémoire lorsque le programme s'arrête alors que certains autres comme de vieux zindow la laissent réservée donc perdue jusqu'au reboot. Quoi qu'il en soit, c'est toujours mieux de libérer ce qu'on a réservé.

Pour être propre, tu devrais écrire :

Code :

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

1
2
3
 
	free(test.toto);
        test.toto = NULL;

Généralement on regroupe les deux instructions pour montrer qu'elles vont ensemble

Code :

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

free(test.toto), test.toto = NULL;

Mais dans l'absolu c'est quand-même inutile. Pourquoi mettre un pointeur à NULL ? Si on le réaffecte plus tard le NULL sera écrasé par la nouvelle adresse. Et si on ne le réaffecte pas ça veut dire qu'on ne s'en sert plus. Dans tous les cas la valeur "NULL" ne sert à rien...

J'ai mis ton printf en commentaire sinon ça va planté...

Ben non. C'est un comportement indéfini donc personne ne peut dire ce qu'il va se passer. Ca peut planter comme pas. Et ça peut marcher pendant 15 jours jusqu'à ce qu'on rajoute un simple printf("hello") en début de code et là ça plante. La plus pure définition du comportement i.n.d.é.f.i.n.i

[jeremy13]

Ben non puisque justement tu demandes que la mémoire soit libérée. Le système peut pas croire qu'elle est restée occupée.
En revanche, si tu oublies le free() alors certains systèmes comme Unix/Linux libèrent automatiquement la mémoire lorsque le programme s'arrête alors que certains autres comme de vieux zindow la laissent réservée donc perdue jusqu'au reboot. Quoi qu'il en soit, c'est toujours mieux de libérer ce qu'on a réservé.


Généralement on regroupe les deux instructions pour montrer qu'elles vont ensemble

Code :

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

free(test.toto), test.toto = NULL;

Mais dans l'absolu c'est quand-même inutile. Pourquoi mettre un pointeur à NULL ? Si on le réaffecte plus tard le NULL sera écrasé par la nouvelle adresse. Et si on ne le réaffecte pas ça veut dire qu'on ne s'en sert plus. Dans tous les cas la valeur "NULL" ne sert à rien...

Prends n'importe quel bouquin de C et il te diras que ça fait un joli "pointeur fou"...c'est une règle d'or!! toujours faire suivre un free par une affectation du pointeur à NULL....

Ben non. C'est un comportement indéfini donc personne ne peut dire ce qu'il va se passer. Ca peut planter comme pas. Et ça peut marcher pendant 15 jours jusqu'à ce qu'on rajoute un simple printf("hello") en début de code et là ça plante. La plus pure définition du comportement i.n.d.é.f.i.n.i

Je viens juste de le tester... :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[])
{
  char *pt=NULL;
 
  printf("%c",*pt);
  system("PAUSE");	
  return 0;
}

Et ben je peux t'assurer que ça plante direct...

[nicolas.sitbon]

En revanche, si tu oublies le free() alors certains systèmes comme Unix/Linux libèrent automatiquement la mémoire lorsque le programme s'arrête alors que certains autres comme de vieux zindow la laissent réservée donc perdue jusqu'au reboot.

Non sous windows, l'espace d'adressage du process ainsi que toutes les ressources allouées sont libérés à la terminaison du process (cf l'ouvrage de richter ou windows internals).

Généralement on regroupe les deux instructions pour montrer qu'elles vont ensemble

Code :

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

free(test.toto), test.toto = NULL;

Mais dans l'absolu c'est quand-même inutile. Pourquoi mettre un pointeur à NULL ? Si on le réaffecte plus tard le NULL sera écrasé par la nouvelle adresse. Et si on ne le réaffecte pas ça veut dire qu'on ne s'en sert plus. Dans tous les cas la valeur "NULL" ne sert à rien...

Si ça sert : si tu ne le mets pas à NULL et que tu t'en ressert en oubliant de l'allouer il peut se passer tout et n'importe quoi et dans le pire des cas (pour le programmeur) il ne se passe rien sur le moment, puis plus tard le programme plante. Si le pointeur est mis à NULL dès que tu tentes de t'en servir s'en l'avoir allouer : SEGMENTATION FAULT, l'erreur est repérée immédiatement.

[nicolas.sitbon]

Je viens juste de le tester... :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[])
{
  char *pt=NULL;
 
  printf("%c",*pt);
  system("PAUSE");	
  return 0;
}

Et ben je peux t'assurer que ça plante direct...

Il y a des librairies "blindés" contre ce genre d'erreur qui afficheront (null) sans terminer le programme.

[jeremy13]

Merci Nicolas, ta réponse me rassure dans mes propos...

[jeremy13]

Il y a des librairies "blindés" contre ce genre d'erreur qui afficheront (null) sans terminer le programme.

oui mais ce sont des librairies externes au C ?

[DidUngar]

oui mais ce sont des librairies externes au C ?

Toute les librairies sont des ajouts, et donc externe au noyeaux pur de base du c.
Mais comme les librairies sont coder en c , pour du c....
Ce n'est pas considéré comme extern mais comme une sous partie qui n'est pas constament utiliser.

Logique, pourquoi mettre en memoire toute les fonctions existante au monde ?
Donc on demande selement celle que l'on veut pour les programme en cours ( d'ou l'utilisation des includes ).

Ensuite je competterai en disai que les librairie disponnible sur ton ordinateur, change en fonction de ton ordi.
En général on as les même base exemple :

Code :

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

1
2
3
 
#include <stdio.h>
#include <stdlib.h>

Mais comme tout le monde peut programmer sa librairie, et que la majorité programme pour leur propre systéme d'exploitation.....

Donc pour conclure : ca ne fait pas partie du c "standard de base", mais s'ajoute comme une librairie avec include.
J'espere avoir répondu à ta question.

[souviron34]

Non sous windows, l'espace d'adressage du process ainsi que toutes les ressources allouées sont libérés à la terminaison du process (cf l'ouvrage de richter ou windows internals).
.

C'est vrai ça.. C'est bien connu que la gestion de la mémoire est un modèle sous Windows mais qu'est-ce qu'y faut pas entendre !!! Et les machines qui bloquent, qu'il faut rebooter car plus rien ne marche, ou ton disque dur tourne en permanence, parce que le swap est plein (quand c'est pas les anciennes versions qui te poppaient "Fatal error 0x07773 ...)

Si ça sert : si tu ne le mets pas à NULL et que tu t'en ressert en oubliant de l'allouer il peut se passer tout et n'importe quoi et dans le pire des cas (pour le programmeur) il ne se passe rien sur le moment, puis plus tard le programme plante. Si le pointeur est mis à NULL dès que tu tentes de t'en servir s'en l'avoir allouer : SEGMENTATION FAULT, l'erreur est repérée immédiatement.

vi mais ça c'est pour les pas bons programmeurs

Non sérieusement, tu t'en fous strictement si ton free est avant le return... Et si tu t'en ressert dans la même fonction, comme dit Sve@r, à moins que ta conception soit nulle (à défaut du pointeur ), il reprendra la valeur affectée par la prochaine alloc..,

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
char *p;
 
if ( (p = malloc(250)) != NULL )
 {
      ....
      free(p);
      ...
      if ( (p = malloc(2500)) != NULL )
        {
             ....
             free(p);
             ...
        }
 }

marchera dans 100% des cas...

[nicolas.sitbon]

C'est vrai ça.. C'est bien connu que la gestion de la mémoire est un modèle sous Windows mais qu'est-ce qu'y faut pas entendre !!! Et les machines qui bloquent, qu'il faut rebooter car plus rien ne marche, ou ton disque dur tourne en permanence, parce que le swap est plein (quand c'est pas les anciennes versions qui te poppaient "Fatal error 0x07773 ...)

Je rappelle au passage que windows a été développez en grande partie par les concepteurs de VMS qui est le système qui a introduit la notion de mémoire virtuelle pour les grandes gueules, et oui personnellement je trouve que la gestion de la mémoire est bien foutue sous windows, bizarrement je ne rencontre aucun des problèmes que tu cites mise à part le dernier mais qui ne peut être incriminé qu'à de mauvais drivers comme c'est souvent le cas. Pour ceux qui mettrait ma parole en doute, dans le bouqin de Richter p107 je cite :

Lorsqu'un processus se termine, son code et toutes les ressources qu'il a allouées sont supprimés de la mémoire.

vi mais ça c'est pour les pas bons programmeurs

C'est vrai Emmanuel Delahaye n'est pas terrible comme programmeur...
http://emmanuel-delahaye.developpez.com/goret.htm

Force 7

* Usage du préfixe _ dans les identificateurs
* Identificateurs abscons
* Absence de prototypes
* Prototype séparé défini dans une fonction.
* Usage injustifié de variables globales privées modifiables.
* usage de free() ou fclose() (ou équivallent) sans remettre le pointeur à NULL

Je reprend ta phrase si ça ne t'ennuie pas : qu'est ce qu'il ne faut pas entendre!

[Sve@r]

Non sous windows, l'espace d'adressage du process ainsi que toutes les ressources allouées sont libérés à la terminaison du process (cf l'ouvrage de richter ou windows internals).

Ptet aujourd'hui. Mais moi j'ai parlé de vieux zindow (comme 95 par exemple). Mais t'as tout à fait le droit d'aimer zindow. Personne ne te le reprochera. Laisse moi le droit de ne pas l'aimer...

Si ça sert : si tu ne le mets pas à NULL et que tu t'en ressert en oubliant de l'allouer

Si tu fais ça c'est donc que ton programme est mal conçu (par ailleurs moi j'ai dit "affecter" et non "allouer" car on peut très bien, plus tard, lui affecter la valeur d'un autre pointeur)

Par ailleurs, Emmanuel est évidemment un super programmeur C mais on a le droit de ne pas être d'accord avec toutes ses affirmations (surtout quand ses affirmations parlent du comportement du programmeur et non du C). En fait, remettre le pointeur à NULL garantit que ton code plante si tu demandes le pointé (alors que ce n'est pas forcément le cas quand le pointeur n'est pas remis à NULL). Ca t'offre donc une protection supplémentaire mais que tu n'es pas obligé de prendre...

[Thierry Chappuis]

Mais dans l'absolu c'est quand-même inutile. Pourquoi mettre un pointeur à NULL ? Si on le réaffecte plus tard le NULL sera écrasé par la nouvelle adresse. Et si on ne le réaffecte pas ça veut dire qu'on ne s'en sert plus. Dans tous les cas la valeur "NULL" ne sert à rien...
i

En complément de la réponse donnée par nicolas.stibon, j'ajouterais que NULL a l'avantage, par rapport à n'importe quelle autre adresse invalide, d'être testable.

vi mais ça c'est pour les pas bons programmeurs

Non sérieusement, tu t'en fous strictement si ton free est avant le return... Et si tu t'en ressert dans la même fonction, comme dit Sve@r, à moins que ta conception soit nulle (à défaut du pointeur ), il reprendra la valeur affectée par la prochaine alloc..,

Certes, cela ne sert à rien lorsque l'appel à free() est placé juste avant une instruction return. Mais bon, ça ne mange pas d'pain de remettre un pointeur à NULL après libération de la mémoire pointée. Et comme je suis un pas bon programmeur, je préfère adopter une attitute idiomatique dans ce cas.

Thierry

[Sve@r]

Mais bon, ça ne mange pas d'pain de remettre un pointeur à NULL après libération de la mémoire pointée.

Tout à fait. Liberté liberté chérie...

En complément de la réponse donnée par nicolas.stibon, j'ajouterais que NULL a l'avantage, par rapport à n'importe quelle autre adresse invalide, d'être testable.

Euh... il y en a d'autres (d'adresse invalide) ???