Discussion :

[callsty]

Bonjour,
je me suis amusé a faire une bête liste chainée et je ne comprends pas pourquoi mon programme prends près de 4 Mo à la fin de l'exécution par rapport au 310 ko de départ.

Si j'appelle ma fonction plusieurs fois, à la fin mon programme prends environ 4,4Mo

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
44
45
46
47
 
#include <stdio.h>
#include <stdlib.h>
 
struct pchar
{
    char caract;
    struct pchar *nextChar;
}pchar;
 
typedef struct pchar* tpchar;
 
void mumuse ()
{
    tpchar testmem;
    tpchar temp;
    tpchar tete_liste;
    int i;
    printf ("je vais prendre de la memoire\n");
    scanf ("%d", &i );
    testmem = ( tpchar ) malloc ( sizeof ( pchar ));
    tete_liste = testmem;
    for ( i = 0 ; i <= 30000000 ; i++ )
    {
        testmem -> nextChar = ( tpchar ) malloc ( sizeof ( pchar ));
        testmem = testmem -> nextChar;
    }
    testmem -> nextChar = NULL;
    printf ("la mémoire est prise\n");
    scanf ("%d", &i );
    testmem = tete_liste;
    while ( testmem != NULL )
    {
        temp = testmem;
        testmem = testmem -> nextChar;
        free(temp);
    }
    printf ("il reste 3 mo...\n", &i );
    scanf ("%d", &i );
}
int main(void)
{
    int i;
    mumuse ();
    scanf ("%d", &i );
    return 0;
}

[pfeuh]

Salut,

Et testmem lui-même, tu ne fais pas de free dessus?

A+

Pfeuh

[curium]

Dans ce programme, la mémoire allouée est correctement libérée. Il n'y a pas de fuite de mémoire ici. Si le programme occupe toujours de l'espace mémoire après avoir utilisé "free", cela provient d'une raison externe au code.

Pour s'en convaincre, on peut remplacer les appels à "malloc" et "free" par des appels à ces fonctions :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
void * malloc_verbeux (int taille)
{
  void * adresse_memoire;
  adresse_memoire = malloc (taille);
  printf ("mall %p\n", adresse_memoire);
  return adresse_memoire;
}
 
void free_verbeux (void * adresse_memoire)
{
  free (adresse_memoire);
  printf ("free %p\n", adresse_memoire);
}

Ainsi, il est facile de s'assurer que les zones mémoires allouées sont bien libérées, du moins tant que le nombre d'allocations ne dépasse pas 5.



Remarque 1 : Lors de la création d'un nouvel élément de liste, il serait judicieux d'initialiser son pointeur "nextChar" à la valeur "NULL".


Remarque 2 : Il est inutile de passer l'adresse de la variable "i" en argument à la fonction "printf". Par exemple, cet appel à la ligne 19 :

Code C :

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

    printf ("je vais prendre de la memoire\n", &i );

serait avantageusement remplacé par :

Code C :

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

    printf ("je vais prendre de la memoire\n");

Remarque 3 : Il est recommandé de tester la valeur de retour de la fonction "malloc", afin de s'assurer que l'allocation mémoire s'est bien déroulée. Elle peut en effet échouer si il n'y a plus assez de mémoire libre. Voici un exemple de code :

Code C :

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

1
2
3
4
  int * adresse_memoire;
  adresse_memoire = malloc (sizeof (int));
  if (adresse_memoire == NULL)
    exit(EXIT_FAILURE);

Remarque 4 : Il est préférable d'utiliser l'une des constantes "EXIT_SUCCESS" ou "EXIT_FAILURE" prédéfinies dans l'entête "stdlib.h" pour désigner la valeur de retour du programme. Autrement dit, dans la fonction "main", il est préférable de remplacer

Code C :

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

    return 0;

par

Code C :

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

    return EXIT_SUCCESS;

Remarque 5 : En langage C, il est préférable d'écrire explicitement les arguments de la fonction "main". Autrement dit, il est préférable de remplacer

Code C :

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

int main()

par

Code C :

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

int main (void)

[callsty]

merci pour les dernières remarques, c'est vrai que je n'ai pas fait attention aux détails car ce programme ne me sert à rien, juste a vous poser cette question existentielle de l'utilisation de la mémoire après les free .

Qui trouvera LA solution ?

[Médinoc]

Si le comportement ne vient pas de malloc(), alors il vient de la plate-forme sur laquelle le programme tourne. Tu dois donc nous préciser l'OS, compilateur, etc.

Attention au passage, rien ne garantit que la mémoire retournée par malloc() soit initialisée à zéro: Le pointeur nextChar de ton dernier chaînon peut contenir n'importe quoi!

[edgarjacobs]

Arrêtez de vous prendre la tête! Les librairies de base sont fiables (bien que j'en ai également douté)

J'ai vu pas mal de questions au sujet de malloc / free / printf, et il s'avère que le problème vient toujours de l'application, et non de la librairie.

Arrêtez de croire que parce que votre application a un problème, il vient de la librairie!

[callsty]

je tourne sur codeblocks, mon compilateur c'est gcc sur mon os: win7
c'est vrai que je n'ai pas mis à NULL le dernier pointage sur le chaînon suivant, la mise à jour est faite et non cela ne résout pas le problème.

Je suis passé sous linux (ubuntu 12.10) pour étudier le comportement du programme, je suis toujours sur codeblocks et mon compilateur c'est encore gcc. Il est a noté que de base mon programme prends moins de ko. Une fois que je prends de la mémoire je passe à environ 900 Mo au lieu de 500 sous windows, le pire c'est que sous linux la mémoire ne se libère pas. Par contre si je relance plusieurs cette même fonction cela ne bouge pas en mémoire je suis toujours à 900 Mo...
J'ai essayé de lancer mon programme dans le terminal et non depuis cb et cela n'a rien changé...

Pour faire simple avez vous déjà vu une liste chainée ne laissant aucune trace en mémoire après avoir fait une multiple allocation? SI oui dans ce cas donnez moi le code car pour l'instant je suis dans l'impasse...

[Sve@r]

Salut

Remarque 1 : Lors de la création d'un nouvel élément de liste, il serait judicieux d'initialiser son pointeur "nextChar" à la valeur "NULL".

Personnellement je suis pour l'initialisation uniquement nécessaire donc mettre le next à NULL n'est pas vraiment utile puisqu'il sera mis à jour lors de l'insertion de l'élément dans la liste. Mais l'autre école (j'initialise systématiquement comme ça je suis tranquille) se justifie aussi surtout avec la puissance sans cesse accrue de nos machines qui permettent maintenant de se moquer de ce petit gaspillage de temps processeur...

Remarque 2 : Il est inutile de passer l'adresse de la variable "i" en argument à la fonction "printf". Par exemple, cet appel à la ligne 19 :

Code C :

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

    printf ("je vais prendre de la memoire\n", &i );

serait avantageusement remplacé par :

Code C :

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

    printf ("je vais prendre de la memoire\n");

C'est plus qu'inutile, c'est même carrément une erreur...

Remarque 3 : Il est recommandé de tester la valeur de retour de la fonction "malloc", afin de s'assurer que l'allocation mémoire s'est bien déroulée. Elle peut en effet échouer si il n'y a plus assez de mémoire libre. Voici un exemple de code :

Code C :

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

1
2
3
4
  int * adresse_memoire;
  adresse_memoire = malloc (sizeof (int));
  if (adresse_memoire == NULL)
    exit(EXIT_FAILURE);

Il est aussi préférable de ne pas utiliser exit pour quitter brutalement une fonction interne et réserver l'entrée/sortie du programme à la seule fonction main()

Code C :

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

1
2
3
4
  int * adresse_memoire;
  adresse_memoire = malloc (sizeof (int));
  if (adresse_memoire == NULL)
    return NULL;

Charge à l'appelant de gérer ce NULL et donc de le remonter à son propre appelant ou bien de faire ce qu'il faut...

Remarque 5 : En langage C, il est préférable d'écrire explicitement les arguments de la fonction "main". Autrement dit, il est préférable de remplacer

Code C :

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

int main()

par

Code C :

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

int main (void)

Peut-être que je me trompe mais je pense que c'est en C++ qu'il faut impérativement spécifier le void et que le C ne l'impose pas (même si c'est pas interdit)...

Attention au passage, rien ne garantit que la mémoire retournée par malloc() soit initialisée à zéro: Le pointeur nextChar de ton dernier chaînon peut contenir n'importe quoi!

En fait, c'est surtout garantit que la zone allouée n'est pas initialisée...

J'ai essayé de lancer mon programme dans le terminal et non depuis cb et cela n'a rien changé...

Pour faire simple avez vous déjà vu une liste chainée ne laissant aucune trace en mémoire après avoir fait une multiple allocation? SI oui dans ce cas donnez moi le code car pour l'instant je suis dans l'impasse...

En fait, je pense que la mémoire est gérée comme le fait une bdd. Par exemple, Postgres gère ses tables par des pages qu'il alloue quand il a besoin. Mais quand on supprime des données des tables, il indique simplement que les pages allouées sont dispo pour d'autres données mais ne les libère pas physiquement. Donc la place utilisée par les données insérées puis effacées ensuite reste quand-même utilisée sur le disque. Il est ensuite nécessaire de faire un vacuum pour qu'il retasse les données réelles et libère l'espace libre.
Et donc peut-être que le free se comporte de la même façon. La mémoire libérée reste allouée au programme lui-même qui pourra donc la réutiliser au malloc suivant. D'ailleurs il existe (sous Windows) des utilitaires sensés scruter les programmes actifs et rendre à l'os ces zones mémoires libérées logiquement mais non physiquement...

[callsty]

Merci beaucoup pour ta réponse Sve@r,
Maintenant la vrai interrogation c'est de savoir comment on libère la mémoire physiquement et non logiquement?
Apparemment c'est vraiment à la charge du système d'exploitation. Si c'est bien le cas je suis tombé dans un problème bien trop complexe a mon niveau je pense.

[curium]

Je viens de le vérifier, le programme écrit par callsty libère correctement toute la mémoire allouée avant de se terminer.

Je ne peux malheureusement pas me procurer la spécification officielle du langage C auprès de l'organisme ISO car cela coûte environ 200 euros, je trouve cela triste. Cependant j'ai trouvé un brouillon daté de 2005 à cette adresse : www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf. Voici ma traduction de cette spécification de la fonction "free".

Synopsis

Code C :

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

1
2
#include <stdlib.h>
void free(void *ptr);

Description

La fonction "free" entraîne la désallocation de l'espace pointé par "ptr", c'est-à-dire que l'espace pointé par "ptr" est rendu disponible pour une allocation ultérieure. Si "ptr" est un pointeur nul, aucune action ne se produit. Dans le cas contraire, si l'argument ne correspond pas à un pointeur précédemment retourné par la fonction "calloc", "malloc", ou "realloc", ou si l'espace a été désalloué par un appel à "free" ou "realloc", le comportement est indéfini.

Valeur de retour

La fonction "free" ne retourne aucune valeur.

Il n'est pas spécifié que la fonction "free" doive rendre la zone mémoire "ptr" disponible pour le système d'exploitation. Elle est seulement obligée de la rendre disponible pour une allocation future lors d'un appel à "malloc", "calloc" ou "realloc".

Je n'en suis pas sûr, mais il me semble donc que si on veut rester conforme au C standard, on ne peut pas obliger le programme à rendre au système d'exploitation de la mémoire allouée via la fonction "malloc". Car il serait possible qu'une implémentation du langage C conforme au standard ait programmé les fonctions "malloc" et "free" de façon à ce qu'elle ne restituent jamais la mémoire non utilisée au système d'exploitation. La seule solution pour libérer la mémoire serait alors de terminer le programme.

[Jean-Marc.Bourguet]

Je viens de le vérifier, le programme écrit par callsty libère correctement toute la mémoire allouée avant de se terminer.

Je ne peux malheureusement pas me procurer la spécification officielle du langage C auprès de l'organisme ISO car cela coûte environ 200 euros, je trouve cela triste.

$30.00 sur le site de l'ANSI. Mais bon, c'est un débat qu'on a déjà eu combien de fois?

Sur la question de rendre la mémoire à l'OS.
1/ Je ne vois pas comment le formuler l'idée dans le cadre de la norme.
2/ Les problèmes de fragmentation font qu'en pratique les cas où c'est possible sont rares, donc en faire une contrainte serait difficile sans exclure des techniques d'implémentation raisonnables.

[callsty]

Merci pour ta réponse Jean-Marc.Bourget
Dans ce cas es qu'il y a un langage ou autre extérieur au c qui puisse forcer à rendre la mémoire? Quels sont les techniques d'implémentation?
Je suis insistant car sur le web je n'ai vu aucune réponses et cela manque cruellement à tout les novices comme moi.

[Kirilenko]

Bonjour,

Je n'en suis pas sûr, mais il me semble donc que si on veut rester conforme au C standard, on ne peut pas obliger le programme à rendre au système d'exploitation de la mémoire allouée via la fonction "malloc". Car il serait possible qu'une implémentation du langage C conforme au standard ait programmé les fonctions "malloc" et "free" de façon à ce qu'elle ne restituent jamais la mémoire non utilisée au système d'exploitation.

C'est d'ailleurs de cette manière que la plupart des allocateurs mémoires fonctionnent : pour des raisons de performance, la mémoire libérée est rajoutée à la liste maintenue par le système d'allocation afin d'être réutilisée lors d'allocations ultérieures. Lorsqu'on n'en a plus, on agrandit la taille du segment de données (à coup de brk p.ex.). Il me semble étrange (du point de vue du concepteur) de vouloir aller à l'encontre de la stratégie du système d'exploitation), pour le coup. Après tout, c'est un peu son problème.

Bonne journée.

[Jean-Marc.Bourguet]

Merci pour ta réponse Jean-Marc.Bourget
Dans ce cas es qu'il y a un langage ou autre extérieur au c qui puisse forcer à rendre la mémoire? Quels sont les techniques d'implémentation?
Je suis insistant car sur le web je n'ai vu aucune réponses et cela manque cruellement à tout les novices comme moi.

Si ce que te fournis l'implémentation ne te conviens pas, il te faut taper en dessous et utiliser directement ce que te fournis l'OS (en t'assurant de ne pas interférer avec l'implémentation). Donc utiliser qqch comme mmap sous Unix.

Le problème est que l'OS gère la mémoire avec une granularité minimale d'une page (valeur typique: 4kb), donc tu va vouloir la découper, et pour la rendre à l'OS il faut t'assurer qu'elle soit complètement inutilisée. C'est un surcoût.

Note que ce que font certains allocateurs, c'est d'utiliser des techniques différentes suivant la taille demandée, et rendre la mémoire à l'OS pour les grandes tailles d'allocation.

[imperio]

Le problème est que l'OS gère la mémoire avec une granularité minimale d'une page (valeur typique: 4kb), donc tu va vouloir la découper, et pour la rendre à l'OS il faut t'assurer qu'elle soit complètement inutilisée. C'est un surcoût.

Tout dépend du système en effet. J'ai souvenir que freebsd a une pagesize de 1 octet justement. Dans tous les cas il suffirait de vérifier si l'adresse qu'on vient de free est la dernière et si oui la rendre de nouveau accessible au système. Il me semblait d'ailleurs que c'était géré de cette façon. Je suis un peu étonné. D'ailleurs, je me demande ce que la pagesize change vraiment pour un système d'exploitation. Pourquoi ne pas en faire une de la même taille pour tous ?

[Jean-Marc.Bourguet]

Tout dépend du système en effet. J'ai souvenir que freebsd a une pagesize de 1 octet justement.

Ça m'étonnerait fortement. C'est plus une caractéristique du processeur que de l'OS

Dans tous les cas il suffirait de vérifier si l'adresse qu'on vient de free est la dernière et si oui la rendre de nouveau accessible au système.

Tu es dans l'optique de sbrk, mais il n'y a pas que ça qui est utilisé.
De plus il te faudrait aussi rendre à l'OS tout ce qui précède et est libre.

D'ailleurs, je me demande ce que la pagesize change vraiment pour un système d'exploitation. Pourquoi ne pas en faire une de la même taille pour tous ?

Les OS utilisent ce que les processeurs fournissent.
Plus elle est faible, plus la taille des structures de données de l'OS utilisées pour gérer une quantité de mémoire est grande et plus il doit faire des opérations pour ce faire. Ça a un coût aussi. La tendance est plutôt à chercher à gérer de grandes pages (ce que les processeurs fournissent depuis un bon moment).

[callsty]

Dans tous les cas il suffirait de vérifier si l'adresse qu'on vient de free est la dernière et si oui la rendre de nouveau accessible au système.

Tu es dans l'optique de sbrk, mais il n'y a pas que ça qui est utilisé.
De plus il te faudrait aussi rendre à l'OS tout ce qui précède et est libre.

C'est intéressant comme idée mais j'ai du mal à voir comment cela fonctionne. Es ce qu'il faut refaire une ré-allocation complète du programme dans la mémoire et supprimer la précédente ?

[curium]

Comme l'a suggéré Jean-Marc.Bourguet, si la façon dont malloc et free sont programmées ne convient pas, il est possible de les réécrire.

Quand on ne sait pas par où commencer, la première chose à faire est de lire leur code source et essayer de le comprendre. Pour le système d'exploitation GNU/Linux, le code source de malloc et free se trouve sur le site de la GNU C Library. On peut le lire en ligne sur le dépôt git de la glibc. On peut accéder directement au fichier source "malloc.c".

Pour écrire sa propre version de malloc et free sous GNU/Linux, il est utile de lire la description des fonctions mmap et munmap, ainsi que la documentation sur la gestion de la mémoire avec la glibc.


Une solution alternative serait de scinder le programme final en deux petits programmes. Le premier petit programme étant un gros consommateur de mémoire, alors que le second n'en consomme que très peu et met beaucoup de temps à s'exécuter. On commencerait par démarrer le premier petit programme, puis, une fois que celui-ci à terminé son travail, il lance le second, en lui passant en argument les résultats dont il a besoin. Voir à ce sujet la documentation de la glibc sur les processus, les descriptions des fonctions execve et system, et la communication inter-processus.


Un conseil : ne pas utiliser de telles techniques d'optimisation. Surtout quand on débute.