Discussion :

[Tex-Twil]

Bonjour,
tout d'abord je ne sais pas si ma question porte plus sur C ou sur Linux donc mes chers modérateurs déplacez le si nécessaire.

J'ai voulu tester ce qui se passe si je ne désaloue pas la mémoire dans un programme C. J'ai fait une boucle avec un malloc à l'interrieur mais pas de free. Si j''exécute le programme, ma mémoire vive explose bien évidemment. Cependant j'ai remarqué que lorsque j'arrête le programme (Ctrl-C) la quantité de ma ram libre redevient exactement la même qu'avant l'exécution.

Quelqu'un pourrait-il m'expliquer ?

merci

[Mat007]

Salut,

Quand un processus s'arrête le système récupère toute la mémoire allouée, il n'y a donc pas de fuite mémoire 'en dehors'...
(quelque part c'est rassurant )

Ceci fait dire à certains qu'allouer quelque chose à la création et ne pas le désallouer en sortie n'est pas grave puisque le système s'en chargera.
(personnellement je préfère tout désallouer, ce n'est en général pas très compliqué de toute façon)

MAT.

[ToTo13]

Mat a raison.
Toutefois, il est bien de désallouer la mémoire :
- je pense que c'est une très bonne habitude de programmation.
- Si tu as un programme un peu conséquent ou si tu veux aller bosser dans une entreprise, il faut désallouer.

[Tex-Twil]

ok merci pour les précisions.

[Franck.H]

J'ajouterais que le comportement dépend surtout de l'implémentation système, sous Linux je sais que le noyau libère les ressources mais sur d'autres systèmes que je ne citerais pas (sans les dénigrer) c'est pas aussi sûr que ca à ce que j'ai une fois crû comprendre

Le mieux reste encore de libérer la mémoire soi même et c'est d'ailleurs recommandé pour le check des memory leak avec Valgrind (sous Linux) par exemple !

[Tex-Twil]

Le mieux reste encore de libérer la mémoire soi même !

évidemment.

Je vais voir Valgrid ça a l'air sympa.

[Jean-Marc.Bourguet]

Quelle que soit la manière dont on quitte un processus, les S.E. libèrent les ressources associées à ce processus. Même DOS le faisait. Ce qui pose problème, ce sont les ressources qui ne sont pas associées à un processus particulier (mémoire partagée, j'ai cru comprendre que de la mémoire allouée par une DLL sous Windows pouvait se trouver dans ce cas, suivant les S.E. il peut y avoir d'autres choses). Passer son temps à tout libérer quand on quitte le programme, ça fait peut-être propre mais je me demande toujours ce que peuvent bien faire certains programmes qui mettent 10 minutes quand on veut les quitter. Une chose qu'il est possible de faire, c'est de rendre la libération conditionnelle avec le préprocesseur ou une variable d'environnement: on peut faire les tests et vérifier qu'on a bien connaissance de tout ce qui est alloué (bien souvent, ce qu'on ignore aurait dû l'être bien avant), mais on ne frustre pas l'utilisateur en prenant du temps pour ne rien faire d'utile.

[InOCamlWeTrust]

J'ai fait une boucle avec un malloc à l'interrieur mais pas de free. Si j''exécute le programme, ma mémoire vive explose bien évidemment.

Etrange, à moins que tu n'accèdes effectivement à l'espace alloué... normalement, "allouer de la mémoire" ne veut pas dire "réserver un espace en mémoire physique" : Linux ne "réserve", normalement, la mémoire que si on y accède (par le biais d'une écriture ou d'une lecture, par exemple). Quand on alloue de la mémoire, rien ne garantit qu'il existe effectivement une ou plusieurs pages mémoire reférençant cette espace alloué.

[Jean-Marc.Bourguet]

Etrange, à moins que tu n'accèdes effectivement à l'espace alloué... normalement, "allouer de la mémoire" ne veut pas dire "réserver un espace en mémoire physique" :

Pas toujours, mais déjà quand on arrive au bout de la mémoire virtuelle, il y a une erreur.

Linux ne "réserve", normalement, la mémoire que si on y accède (par le biais d'une écriture ou d'une lecture, par exemple).

C'est un peu plus compliqué que cela. L'overcommit est contrôlé par d'au moins deux manières: /proc/sys/vm/overcommit_memory et /proc/sys/vm/overcommit_ratio. Chez moi le premier est à 0 (et je ne me souviens pas avoir fait quelque chose pour cela, mais ce n'est pas impossible que je me trompe), donc il n'y en a pas du tout. Le deuxième "fichier" à voir son nom doit limiter la quantité qu'on peut dépasser. Donc l'allocation peut échouer aussi à cause de cela. (Je trouve stupide que ce contrôle soit global pour le système: pour moi ça devrait être par process).

[Emmanuel Delahaye]

Quelle que soit la manière dont on quitte un processus, les S.E. libèrent les ressources associées à ce processus. Même DOS le faisait.

En sortant par exit() ou un return du main(), oui. J'ai par contre des souvenirs de gamelles mémorables avec Borland C 3.1 après des sorties à la barbare sur un assert().

A la première recompilation : système planté avec "Not enough memory" -> reboot...

Pas tellement sous DOS véritable (6.22) ni WIndows 3.x, mais plutôt sous Machine Virtuelle DOS de Windows 98.

Y'a encore des bits collés sur les murs de mon ancien bureau...

[InOCamlWeTrust]

Pas toujours, mais déjà quand on arrive au bout de la mémoire virtuelle, il y a une erreur.

Certes, on est d'accord.

D'ailleurs, un bon moyen de faire planter un système du style Linux, c'est de vérouiller brutalement toutes les pages accessibles depuis le processus (c'est la fonction mlock je crois, ou quelque chose dans ce style-là).

Il faudrait essayer, juste pour voir et se marrer un bon coup !

[Jean-Marc.Bourguet]

En sortant par exit() ou un return du main(), oui. J'ai par contre des souvenirs de gamelles mémorables avec Borland C 3.1 après des sorties à la barbare sur un assert().

A la première recompilation : système planté avec "Not enough memory" -> reboot...

Pas tellement sous DOS véritable (6.22) ni WIndows 3.x, mais plutôt sous Machine Virtuelle DOS de Windows 98.

Je trouve ça bizarre, ça ne correspond pas tellement à mon souvenir de programmation sous DOS, mais il est vrai que je me suis arrêté à Windows 3.1 (et encore, j'ai pas tellement programmé avec Windows à l'époque). D'après mes souvenirs, les reboot après crash était dus à de la corruption des structures de donnée internes de DOS.

Je suis passé à Linux dès fin 1994 pour mon utilisation personnelle -- mon utilisation professionnelle étant alors sous SunOS, Ultrix et accessoirement VMS -- n'utilisant plus Windows que pour les jeux.

[Emmanuel Delahaye]

Je trouve ça bizarre, ça ne correspond pas tellement à mon souvenir de programmation sous DOS, mais il est vrai que je me suis arrêté à Windows 3.1

assert() sort par abort() (ou _abort()) au lieu de exit(). C'est probablement la raison. Depuis que j'ai réécris la fonction de sortie appelée par assert() avec exit(), je n'ai plus jamais eu ce problème.

http://emmanuel-delahaye.developpez....d/inc/assert.h
http://emmanuel-delahaye.developpez....d/src/assert.c