désallocation de mémoire

Version imprimable

18/10/2006, 01h40
Tex-Twil

désallocation de mémoire

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. :roll: 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 :)
18/10/2006, 03h08
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 :P)

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.
18/10/2006, 08h28
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.
18/10/2006, 10h11
Tex-Twil

ok merci pour les précisions.
18/10/2006, 10h17
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 !
18/10/2006, 10h21
Tex-Twil

Citation:

Envoyé par Franck.H

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

évidemment.

Je vais voir Valgrid ça a l'air sympa.
18/10/2006, 11h55
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.
18/10/2006, 13h33
InOCamlWeTrust

Citation:

Envoyé par Tex-Twil

J'ai fait une boucle avec un malloc à l'interrieur mais pas de free. :roll: 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é.
18/10/2006, 13h40
Jean-Marc.Bourguet

Citation:

Envoyé par InOCamlWeTrust

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.

Citation:

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).
18/10/2006, 21h41
Emmanuel Delahaye

Citation:

Envoyé par 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.

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...
18/10/2006, 23h09
InOCamlWeTrust

Citation:

Envoyé par Jean-Marc.Bourguet

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 !
19/10/2006, 07h42
Jean-Marc.Bourguet

Citation:

Envoyé par Emmanuel Delahaye

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.
19/10/2006, 10h09
Emmanuel Delahaye

Citation:

Envoyé par Jean-Marc.Bourguet

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