Discussion :

[moldavi]

Je ne sais pas ou poster ce message mais comme je programme en C et C++, ben je le poste ici.

J'utilise la surcharge des opérateurs new et delete afin de suivre le bon déroulement de la gestion de la mémoire dynamique.

Mais si on veut suivre de très près cette mémoire cela veut dire qu'il faudrait surcharger tous les opérateurs et toutes les fonctions qui font de l'allocation dynamique.

Un travail assez fastidieux, mais envisageable certe.

Sous linux par exemple l'espace d'adressage d'un processus est de 3 gigaoctets. Lorsque ce processus viole cette espace c'est le signal d'erreur assuré.

Existerait-il un moyen de surveiller tout ce qui se passe au niveau de la mémoire dynamique. Une idée comme ça, à l'arrache, j'alloue le maximum de mémoire autorisée, je la rempli de zéro (ou de 0xff). Je sais ce que j'alloue donc je peux contrôler la correspondance.

Je sais aussi qu'avec l'opérateur new ça ne doit pas se passer aussi simplement que ça, mais ce serait histoire de savoir s'il existe des possibilités.

Est-ce que c'est vraiment très complexe et est-ce qu'un débugeur ne fonctionne-t-il pas de la sorte.

Merci pour vos éclaircissements.

[CroustRyu]

Je ne m'y connais pas assez en surcharge d'opérateur new pour te répondre, mais je voulais apporté une précision à ceci :

Est-ce que c'est vraiment très complexe et est-ce qu'un débugeur ne fonctionne-t-il pas de la sorte.

Non, pas du tout, un déboggueur fait tourner tout programme de tel sorte que lorsque celui-ci plante, lui ne plante pas.

Ensuite lorsque qu'un plantage de ton programme arrive, deux choses :
- il récupere le statut du plantage (via les api de debug des OS par exemple)
- il recupere la valeur du pc de ton programme (pc : program counter) et fait un map grâce aux infos de debug avec ton source.

Voilà -très- grossièrement le principe.

[Duguesclin]

Si tu cherches une inspiration, tu peux aller telecharger les sources d'un détecteur de fuite de memoire (en anglais)

http://wyw.dcweb.cn/leakage.htm

[Aurelien.Regat-Barrel]

Mais si on veut suivre de très près cette mémoire cela veut dire qu'il faudrait surcharger tous les opérateurs et toutes les fonctions qui font de l'allocation dynamique.

Que veux-tu dire ?

Existerait-il un moyen de surveiller tout ce qui se passe au niveau de la mémoire dynamique. Une idée comme ça, à l'arrache, j'alloue le maximum de mémoire autorisée, je la rempli de zéro (ou de 0xff). Je sais ce que j'alloue donc je peux contrôler la correspondance.

La correspondance entre quoi et quoi ?

Les opérateur new/delete reposent eux-même sur des fonctions système d'allocation. Il sont une couche intermédiaire qui gère elle même sa mémoire. La manière de gérer est propre à chaque compilateur / bibliothèque standard. Par exemple y'a des lib qui vérifient au moment du delete que ça n'a pas déjà été delete, que y'a pas eu de dépassement d'écriture, etc...

[moldavi]

Que veux-tu dire ?

Par exemple lorsque l'on ouvre un fichier et que l'on oublie de le fermer pour une raison ou pour une autre, alors il y a une fuite de ressource. Lorsque l'on utilise les objets COM et que l'on oublie de les release, etc...

Tout ces petits détails qui peuvent provoquer des fuites de mémoire ou de ressources lorsque le programme devient important en taille.

Ca voudrait dire suire surcharger CoCreateInstance() ou fopen(), etc...

Code :

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

1
2
 
La correspondance entre quoi et quoi ?

C'est un exemple. Si j'alloue un bloc de mémoire et que je remplis chaque octet avec une valeur choisi (0xff). Je sais dans mon programme à quel moment j'alloue ou je désalloue la mémoire, je sais quelle taille aussi. Je pourrai donc parcourir chaque octet jusqu'à la taille maximale allouée en vérifiant que tout est à Zéro (pointeur NULL), et que le reste vaut 0xff.

[dok3]

tout d'habord a lire :
http://loulou.developpez.com/tutorie.../partie1/#L2.2

ensuite objet COM ou pas les allocation/desalocation passent toutes par les deux couples de fonction que sont new/delete et malloc/free sachant que l'on est en C++ on peut "raisonnablement" oublier le deuxieme couple.

ta solution de "remplir" la memoire me semble totalement utopique, essaye de faire un new [3Giga] ...

Les chose a faire dans l'ordre pour eviter les probleme de fuite memoire, avoir de la rigeur dans son code, savoir ce que l'on fait, utiliser des smart pointer, avoir de la rigeur dans son code (2), savoir ce que l'on fait (2), utiliser des outils de surveillances

pour la fermeture des streams, si elle n'est pas faite explicitement la destruction de l'objet s'en charge

[moldavi]

Pour les "memory leaks", c'est à peu près le même fonctionnement que j'utilise.

Je vais essayer d'être plus précis. Je voudrais surveiller l'espace d'adressage que le système d'exploitation aura alloué à mon programme: sa position en mémoire en quelque sorte, sachant que cette adressage peut-être relatif (pagination, mémoire virtuelle). D'où la complication éventuellement envisageable.

Je voudrais savoir si l'on peut surveiller la pile et le tas en quelque sorte puisque c'est là (le tas) ou se font les allocations dynamiques. De ce fait il serait peut-être possible de détecter les fuites de mémoire.

[moldavi]

ta solution de "remplir" la memoire me semble totalement utopique, essaye de faire un new [3Giga] ...

Je sais, j'ai souvent des idées tordues. C'est aussi la raison pour laquelle je poste ce message.

Par contre, je viens d'essayer ceci:

Code :

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

1
2
 
 void* ptr = new char[1000000000];

Et bien ça marche (c'est très long, mais ça marche...). Pourquoi, parce que le système d'exploitation fait déborder son allocation vers la swap et non pas la mémoire vive. D'ailleurs je n'ai pas 1Go de RAM.

[Laurent Gomila]

A noter qu'on peut utiliser des pointeurs intelligents même pour gérer des ressources COM (pas que des pointeurs bruts). Ainsi on s'assure de ne jamais oublier un AddRef() ou un Release().
Et de manière plus générale on peut adapter les pointeurs intelligents à tout type de ressource.

Voir : http://loulou.developpez.com/tutorie...artie4/#L2.1.2

[moldavi]

A noter qu'on peut utiliser des pointeurs intelligents même pour gérer des ressources COM (pas que des pointeurs bruts). Ainsi on s'assure de ne jamais oublier un AddRef() ou un Release().
Et de manière plus générale on peut adapter les pointeurs intelligents à tout type de ressource.

Je me suis largement inspiré de ton tutorial pour gérer mes ressources.

Imaginons que j'utilise une librairie qui est buggé... et qui oublie de libérer des ressources qu'elle a alloué...

J'ai aussi entendu parler de programme qui à force d'allouer et de désallouer provoque une fragmentation de la mémoire, d'où une perte de performance.
Comment gérer ceci, si l'on ne surveille pas la mémoire du processus.

Peut-être que cette fragmentation de mémoire n'existe plus depuis que les systèmes d'exploitation limitent l'espace d'adressage?

[Aurelien.Regat-Barrel]

Luc pourrait te parler du RAII, qui consiste à libérer les ressources acquises dans le destructeur. Ainsi en C++ si tu oublies de fermer un fstream, ce sera fait automatiquement dans son destructeur. Les pointeurs intelligents c'est un peu pareil, le destructeur se débrouille pour savoir s'il faut libérer l'objet ou non.

C'est un exemple. Si j'alloue un bloc de mémoire et que je remplis chaque octet avec une valeur choisi (0xff). Je sais dans mon programme à quel moment j'alloue ou je désalloue la mémoire, je sais quelle taille aussi. Je pourrai donc parcourir chaque octet jusqu'à la taille maximale allouée en vérifiant que tout est à Zéro (pointeur NULL), et que le reste vaut 0xff.

Tu veux dire un gestionnaire de mémoire qui ferait ça pour s'assurer que tout est libéré ? Mais y'a beaucoup plus simple et efficace : déjà simplement compter le nombre d'allocation / desallocation. A la fin ils doivent être égaux. Les compilos ont leur particularité de ce cote là. VC++ par exemple peut te lister à un moment donné les numéros d'allocations non libérés. Si tu lui demande à la fin du main, c'est de la mémoire non libérée. Tu peux alors lui demander de poser un breakpoint sur l'allocation problematique et tu y sera amené à l'exécution (identique) suivante.
C'est le minimum qu'on peut attendre d'une lib de recherche de fuites de mémoires. Y'a bcp mieux, y'a des outils spécialisés très sophistiqués.
Pour les autres types d'allocation de ressource, la solution est spécifique à chaque cas. Pour les objets GDI y'a des outils spéciaux, pour les autres objets Windows (fichiers, ...) tu peux lister les handle ouverts d'un process, pour COM je sais pas.

[moldavi]

VC++ par exemple peut te lister à un moment donné les numéros d'allocations non libérés. Si tu lui demande à la fin du main, c'est de la mémoire non libérée. Tu peux alors lui demander de poser un breakpoint sur l'allocation problematique et tu y sera amené à l'exécution (identique) suivante.

Tu peux m'expliquer un peu plus comment on utilise cette option avec VC++. En effet, ça m'a l'air beaucoup plus simple comme solution.

[Aurelien.Regat-Barrel]

Imaginons que j'utilise une librairie qui est buggé... et qui oublie de libérer des ressources qu'elle a alloué...

ben tu peux pas y faire grand chose...

J'ai aussi entendu parler de programme qui à force d'allouer et de désallouer provoque une fragmentation de la mémoire, d'où une perte de performance.
Comment gérer ceci, si l'on ne surveille pas la mémoire du processus.

la fragmentation apparait naturellement au fil de l'exécution des programmes. Plus on fait d'allocation / desallocation et plus vite elle risque d'apparaitre, surtout avec des objets de petite taille. C'est aussi fortement dépendant de l'implémentation de la bibliothèque standard ainsi qu'à l'OS sous-jacent. La fragmentation en RAM n'est pas bien grave au point de vu performances, car RAM = accès aléatoire. De plus le mécanisme de pagination fait que les pages de VM les plus sollicitées se retrouvent en RAM. Le pblm de la fragmentation c'est la perte d'espace mémoire. Si tu as plein de petits trous trop petits pour satisfaire des allocations, tous les petits trous c'est de la mémoire perdue. Plus tu alloues beaucoup de tous petits objets et plus la fragmentation est élevée. A force ça impacte en performances car ça oblige à swapper, sauf si comme moi t'as 2Go de RAM et le swap désactivé 8)
Mais y'a des parades. Deja std::string de VC++ 7 par exemple n'alloue pas de mémoire pour les toutes petites chaines (<16 octets). Ensuite si tu dois quand même allouer beaucoup de petits octets, tu peux créer ton allocateur de type pool (y'a une bonne explication sur boost : http://www.boost.org/libs/pool/doc/concepts.html)
Là dessus on peut être déçu d'apprendre qu'un garbage collector style .Net peut se révéler plus efficace qu'une gestion manuelle de la mémoire en C++, car le GC crée des catégories d'objets en fonction de leur durée de vie / taille, et surtout comme c'est pas des pointeurs bruts il est capable de défragmenter son tas...

Peut-être que cette fragmentation de mémoire n'existe plus depuis que les systèmes d'exploitation limitent l'espace d'adressage?

l'espace d'adressage a toujours été limité. Sur un PC 32 bits il est limité à 32 bits, sur un 16 bits à 16 bits (sauf extensions...), etc... La fragmentation n'est pas lié à ça. Elle existe aussi dans les systèmes de fichier par exemple.

[moldavi]

Aurelien.Regat-Barrel ce site trés intéressant. Ca me donne quelques idées.

l'espace d'adressage a toujours été limité. Sur un PC 32 bits il est limité à 32 bits, sur un 16 bits à 16 bits (sauf extensions...), etc... La fragmentation n'est pas lié à ça. Elle existe aussi dans les systèmes de fichier par exemple.

Je voulais parler de l'espace d'adressage du processus (les fameux 3Go sous linux). Etant donné que notre programme posséde 3 Go d'espace, alors les allocations et les désallocations se font à l'intérieur, sinon comment le système d'exploitation pourrait gérer les programmes). C'est donc la raison pour laquelle, je me demandais si ce problème existait toujours puisque le système d'exploitation va aller chercher de la place libre à l'interieur de cet espace

Lorsque le programme a besoin de mémoire l'OS commence-t-il à chercher au début du tas ou bien avance-t-il à chaque fois de bloc en bloc (même si des blocs précédents ont été désalloués). Mais lorsque il arrive à la limite de l'espace d'adressage et qu'il y a des blocs de libres, il doit bien tenter d'allouer à cet endroit là?? ou peut-être qu'il va nous dire, vous avez dépasser la limite de l'espace d'adressage et NEW va nous retourner un pointeur NULL?

[Aurelien.Regat-Barrel]

Je voulais parler de l'espace d'adressage du processus (les fameux 3Go sous linux). Etant donné que notre programme posséde 3 Go d'espace, alors les allocations et les désallocations se font à l'intérieur, sinon comment le système d'exploitation pourrait gérer les programmes). C'est donc la raison pour laquelle, je me demandais si ce problème existait toujours puisque le système d'exploitation va aller chercher de la place libre à l'interieur de cet espace

Attention. L'espace d'adressage est de 4Go, mais 1Go est réservé au système, et un process peut, au maximum, utiliser 3Go. Mais ça veut pas dire qu'il les a dès le départ! Pour avoir droit d'utiliser le moindre octet sur ces 3Go max qui lui sont autorisés, il doit le demander à l'OS. Toi tu veux remplir de zéros => il faut allouer auprès de l'OS ce que tu veux remplir. Essaye d'aller écrire comme ça à l'adresse 2Go, tu va être déçu

Lorsque le programme a besoin de mémoire l'OS commence-t-il à chercher au début du tas ou bien avance-t-il à chaque fois de bloc en bloc (même si des blocs précédents ont été désalloués). Mais lorsque il arrive à la limite de l'espace d'adressage et qu'il y a des blocs de libres, il doit bien tenter d'allouer à cet endroit là?? ou peut-être qu'il va nous dire, vous avez dépasser la limite de l'espace d'adressage et NEW va nous retourner un pointeur NULL?

new c'est un truc C++, l'OS il connait pas new. L'OS il exporte des focntions système qui permettent d'allouer des blocs de mémoire. L'OS, il gère l'allocation de blocs de mémoire, c'est tout. Il se le gère à sa façon, chacun sa méthode. Si la mémoire virtuelle est saturée, il refuse l'allocation et voilà. Sinon, il te réserve un petit bloc dans la mémoire dispo, et te donne le droit d'y accéder.
Maintenant, en C++, ton programme il est pas tout nu comme ça avec sa fonction main(). En réalité avant l'appel de main() tu as la bibliothèque standard de ton compilo qui prend la main (lol, main/main()). C'est elle qui va appeler ton main(), une fois qu'elle se sera initialisée. Lors de son init, elle va demander à l'OS un assez gros bloc, disons (au pif hein) 100Ko. Elle appelles main(). Dans ton main tu fais un new => hop c'est la lib standard qui reprend le controle, elle sait qu'elle a 100Ko de libre, hop elle te file les octets que tu as demandé dans ces 100Ko et voilà new réussi. Et on continue comme ça. Au bout d'un moment, les 100Ko sont plein. Alors elle va demander à nouveau 100Ko à l'OS, ou plus/moins. Il les lui donne, tout va bien on continue. A force a force un jour l'OS refuse, alors la lib standard peut rien faire, elle lance bad_alloc.
Ca c'est un exemple. L'histoire des 100Ko c'est chaque lib standard (fournie avec chaque compilo) qui décide ce qu'elle fait. Une mauvaise lib pourrai directement demander à l'OS de faire l'alloc demandée, sans faire de tampon. C'est mauvais car un appel système c'est très lourd : le kernel doit reprendre le controle, etc...
Tout ce qui est détection des fuites etc... c'est la lib standard qui le fait, pas l'OS. Genre tu fais new char[ 100 ], masi elle elle va pas allouer 100 octets, mais plus que cela, déjà pour savoir que y'a 100 et quelques octets à libérer lors du delete, mais aussi en Debug par exemple pour rajouter des 0xFF comme tu dis au début et à la fin pour tester si ça a débordé, etc...

[moldavi]

C'est bien ce qui me semblait, c'est compliqué à mourrir

A part faire ça avec le noyau Linux et modifier les sources...

Je suis un peu déçu d'apprendre qu'il n'y a pas de moyen précis de contrôler la mémoire utilisée par son programme (à part la surchage d'opérateurs ou autres techniques).

Dommage

Mais bon ce soir je dormirais moins bête, et puis ça me fera du bouleau en moins

[Aurelien.Regat-Barrel]

La mémoire allouée avec new/delete oui c'est facile, et c'est déjà fait, et même plus (valgrind, purify, insure++, AQtime, boundschecker, ...). Le reste, c'est au cas par cas.

[Luc Hermitte]

Luc pourrait te parler du RAII, qui consiste à libérer les ressources acquises dans le destructeur.

Oui. Tout à fait.

De plus ces histoires de surveiller les ressources ne sont pas vraiment généralisables -- un pot de peinture est aussi une ressource. En supposant que l'on puisse détourner correctement la gestion de la mémoire, il y a quantité de types de ressources différentes. Et avec le RAII, le C++ nous permet d'avoir une gestion (!= surveillance) uniformisée de celles de notre code -- on ne peut rien pour ce qui est des ressources gérées internement par une bibliothèque tierce.

Pour ce qui est de COM ... les smart pointers sont nos amis. Dans mes souvenirs, ils s'intègrent parfaitement et très facilement -- j'utilisais COM sauce ATL.