Discussion :

[Woufeil]

Bonjour,

Désolé, je ne sais vraiment pas où poster ce message... Etant donné qu'il contient du code C++ je le poste ici.

Imaginons ce bout de code très simple :

Code :

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

1
2
3
4
5
int main(int argc, char** argv)
{
    int* var = new int;
    return 0;
}

Comme vous le voyez, la mémoire n'est pas libérée par un delete... Je me demandais si à la fin de l'exécution du programme (et non pas du bloc contenant le new, même si dans ce cas cela revient au même) la mémoire serait finalement libérée...
Cela dépend forcément de l'OS (c'est pour ça que je ne sais pas si mon message à sa place ici), je voulais donc juste savoir si un Windows XP ou un Linux avec un kernel à jour laisse passer ce genre de fuites ou non. Je suppose qu'il doit y avoir une espèce de garbage collector intégré à l'OS mais je n'en suis pas sûr...

Merci !

[Médinoc]

Un OS récent ne laisse pas passer ce genre de fuite: Toute la mémoire d'un processus est libérée à la fin de celui-ci (ce n'est pas une histoire de GC, c'est que la mémoire est toujours associée au processus qui la possède).

Sous Win32, tous les handles que possède un process sont également fermés, et tous les objets de synchronisations sont détruits quand le dernier handle sur lui est fermé...

[Alp]

Et si l'on fait un programme ou il y a de nombreux oublis de delete, l'OS va tout ramasser après?
Mais pourquoi XP ne (apparemment) ramasse-t-il pas ou mal?

[Médinoc]

Si si, XP ramasse tout, comme tous les systèmes NT. Mais seulement à la fin d'un programme ---> Pour un serveur, c'est un peu mort.

Àprès, il y a d'autres choses que XP garde en cache, comme les exécutables ou certains fichiers... Mais là ce n'est pas un bug, c'est une feature.

[WebPac]

Heureusement que les OS récents récupèrent la mémoire car quand on voit comment les applications utilisent la mémoire en général, un serveur serrait très rapidement à cours de ressource, hors on ne redémarre pas un serveur comme on le faisait avec win98 alors qu'il travaille beaucoup.

Pour exemple, Firefox gère mal la mémoire, il ne libère tout qu'en le fermant, donc est-ce lui ou l'OS qui fait le travail ? Le mystère est entier.

[Médinoc]

Pour FF, c'est une feature aussi (mise en cache des fichiers téléchargés). Mais la partie idiote, c'est quand le "cache mémoire" (par opposition au "cache disque") se met à déborder en mémoire virtuelle (voire même à dépasser la mémoire virtuelle, forçant Windows à l'augmenter), annulant son efficacité.
Il est possible de limiter la taille du cache disque sous FF, mais pas celle du cache mémoire...

[Woufeil]

Si quelqu'un peut m'expliquer grossièrement (ou me donner une doc qui explique) comment il est possible de savoir combien de mémoire dans le tas un programme a utilisé au cour de son exécution, je suis preneur... Par définition, on ne le sait pas lors de la compilation, alors comment ça se passe ? Un espace précis du tas est allouée lors de l'exécution du programme et le programme l'utilise à sa guise ? Ca serais étonnant...

[WebPac]

Pour FF, c'est une feature aussi (mise en cache des fichiers téléchargés). Mais la partie idiote, c'est quand le "cache mémoire" (par opposition au "cache disque") se met à déborder en mémoire virtuelle (voire même à dépasser la mémoire virtuelle, forçant Windows à l'augmenter), annulant son efficacité.
Il est possible de limiter la taille du cache disque sous FF, mais pas celle du cache mémoire...

Bizarre, dans les news annonçant la V2 de Firefox, il est dit que cette version corrige le BUG de la non libération de mémoire de firefox (sauf à sa fermeture). Cela était bien présenté un bug. Il faudrait que je retrouve l'article.

Si ce n'était pas un bug, ce n'est quand même pas pratique, car si on ne ferme pas firefox (ce qui souvent le cas), on se retrouve avec plus de 200 Mo de mémoire utilisée alors qu'on peut n'avoir qu'1 ou 2 onglets d'ouvert.

[Médinoc]

En effet, ce que j'appelle "la partie idiote" est sans doute un bug.

Woufeil : Tu veux dire à des fins de débogage ou pour l'OS ?
Car l'OS sait en permanence à quel process appartient telle page mémoire. C'est lui qui gère l'allocation, après tout.

Ensuite, dans les pages mémoires allouées à un process, il crée les différentes zones de code ou de données, dont un tas (oui, un par process) qui généralement peut grandir pour consommer plus de pages (c'est le cas de Windows, en tout cas, sauf qu'un process peut carrément demander la création de tas supplémentaires avec HeapCreate()).

Lorsqu'un tas est détruit, la mémoire allouée "dans" se tas est donc considérée comme libérée (le tas lui-même n'existe plus) et les pages mémoire utilisées deviennent libres pour l'OS.
Quand un process se termine, toutes les pages qui appartenaient à ce process sont libérées par l'OS.


Donc, en fait, il n'y a pas UN tas mais deux niveaux de tas: Celui géré au niveau du kernel et de la MMU (Memory Management Unit) qui gère toute la mémoire virtuelle d'un process et qui se mesure en pages mémoire, et le tas créé pour chaque process au sein de l'espace qui lui a été alloué par le kernel.

[rigobert]

Si quelqu'un peut m'expliquer grossièrement (ou me donner une doc qui explique) comment il est possible de savoir combien de mémoire dans le tas un programme a utilisé au cour de son exécution, je suis preneur...

Sous Windows on peut connaitre la mémoire allouée dans le tas par différence d'état, en appelant plusieurs fois (au moins 2) la fonction _CrtMemCheckpoint() puis éventuellement _CrtMemDifference().

[Médinoc]

Mais ça, c'est uniquement pour le "CRT Debug Heap" (Tas de débogage de la C Run-Time Library), qui me semble-t-il, ajoute des informations pour cela...

[Woufeil]

Merci !

€dit : je ne savais pas qu'il y avait un tas par process en fait. Vu que le tas est représenté comme un espace bordélique (pas d'ordre quoi) je me diais qu'on utilisait le même pour tout, ce qui est en fait assez con...

[WebPac]

Comme disait Louis XVI enfant dans le bac à sable :

Les tas c'est moi !

Bon ok, je sors.

[Luc Hermitte]

Parenthèse. Aujourd'hui, a peu près tous les OS maintenus sauront récupérer la mémoire consommée par un process. Même si ce dernier ne l'a pas correctement récupérée explicitement.
Par contre, ce n'est pas vrai pour les autres ressources (à quelques exceptions près liées à l'OS). Un pot de peinture alloué via une API propriétaire ne sera pas collecté à la terminaison du process.
Des bouts de FAQ connexes à cela -> RAII.

[koala01]

Salut,

Je me suis amusé à créer un gestionnaire de mémoire pour la période de débuggage en C++...

Ce n'est pas tres évolué, dans le sens ou il ne prend en compte que les operateurs new, new[] (en indiquant le fichier et la ligne à laquelle il est survenu), delete et delete[], mais il a au moins l'avantage d'exister, de prendre en charge le logging des allocations/libérations mémoire, incluant un rapport des pointeurs non libérés (et leur libération) ainsi que celui des éventuelles exceptions rencontrées durant son office, et d'être, théoriquement compatible linux et windows (en tous cas, avec les compilos que j'ai testés)

Il est possible d'activer/désactiver l'affichage de l'ensemble des informations à l'écran, et les logs sont en francais.

Pour ceux que cela intéresse, voici le zip des fichier utilisés, les codes sources étant relativement bien commentés, il vous "suffira" théoriquement d'inclure le fichie debug/enabledebug.h dans les entetes de vos codes sources

Nota: les critiques constructives seront les bienvenues ...Surtout si elles devaient me permettre de gérer, par exemple la destruction implicite des objets lors de la destruction d'une référence en fin de routine