Version imprimable
Bonjour a tous,
je fais un simple main "new int", sans delete, et j appelle
_CrtDumpMemoryLeaks juste avant la fin du main.
Ca m affiche dans le output, un block de 8 octets non desaoulle, ce qui est parfait.
Par contre quand je fait virtualAlloc, qui reserve la memoire aussi, DumpMemoryLeaks n affiche rien, pourtant il existe une methode VirtualFree. Donc je me demande bien pourquoi y a pas de fuites memoires dans ce cas precis.
Merci d avance chers forumers
http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx
et surtout :
Je pense que ça vient de là. En tout cas, la détection de memory leaks étant fortement liée à l'allocateur mémoire, ce n'est pas étonnant que par défaut ça ne fonctionne pas si tu n'alloues pas avec malloc/free (ce que fait new).Citation:
By default, internal C run-time blocks (_CRT_BLOCK) are not included in memory dump operations. The _CrtSetDbgFlag function can be used to turn on the _CRTDBG_CHECK_CRT_DF bit of _crtDbgFlag to include these blocks in the leak detection process.
Je pense qu'il y a une méconnaissance du sujet.Citation:
Envoyé par kaiser92
D'un coté l'OS, de l'autre le compilateur et "tout ce qu'il fait en cachette". Les fonctions proposées par le compilateur pour détecter les fuites de mémoire ne concernent que les appels passant par le gestionnaire de mémoire du compilateur (à priori uniquement new/delete et malloc/calloc/realloc/free), aucunement les appels système.
VirtualAlloc est un appel système.
En fait je pose cette quesion car je travaille sur le Boehm GC, qui fait uniquement des VirtualAlloc sans faire les VirtualFree du tout, donc je voulais savoir si le systeme libere la memoire quand le main retourne, c est ce que j ai cru comprendre en lisant les commentaires du code.
Je veux juste en etre sur.
Merci
C'est pas beau de pas libérer, mais oui, sur les systèmes modernes, lorsqu'un processus meurt, tout l'espace mémoire qu'il occupait est libéré.
Ce n'était pas le cas sous windows 95, par exemple...
il me semble que quand tu fait des new sans les deleter, quand l application se termine la memoire physique est encore occupée.
Et quand tu fait dans une boucle new/delete par exemple, la memoire virtuelle diminue, et meme avec le delete, cette memoire virtuelle n'est pas libérée, c'est l'objet d un de mes posts VAS fragmentée.
Peut etre qu'a cause de ca, VirtualAlloc avec certains parametres, n 'a pas besoin d etre libérée, puisque la memoire virtuelle ne se libere pas quand l application se termine, mais quand Windows decide de la liberer.
Je trouverais etonnant que le Boehm GC ne fasse pas de VirtualFree, alors qu'il est utilisé par des milliers de personnes, et que j'utilise une version 7.1 hyper stable.
Certainement une raison pour ca.
Décidément, tu as du mal avec mémoire physique/virtuelle oO.
Physique = tes barrêtes de ram, virtuelle = ce que l'OS te fais voir (au travers de OS est aussi du MMU). Autant dire que la physique, tu n'est pas près d'y toucher.
Et personnellement, avec MINGW 4.4.0 sous XP SP2, j'ai pas ce genre de problème >< de "fragmentation" (mot totalement inapproprié, parle plutôt de fuite) mystère.
Tout processus est ces ressources sont contrôler par l'OS. Aussi va-t-il les récupérer s'il estime cela nécessaire. C'est généralement le cas à la fin d'un programme...
je pense avoir suffisament fait de recherche pour te dire clairement que new/delete en boucle ne libere pas l'espace virtuel.
Fait ca dans une boucle infinie le soir avant de quitter le bureau et revient le lendemain tu verra que tu devra rebooter ton PC car ta memoire virtuelle sera pleine.
Ta memoire physique est allouee/liberee, en dents de scies.
Y a le concept de private bytes et virtual bytes.
Est-tu en mesure de me dire si VirtualAlloc sans VirtualFree est mal? car le Boehm GC le fait non stop.
Voila
J'y vois aucun problème. Le truc, c'est qu'il n'alloue que lorsqu'il en a besoin. Si jamais il récupérer de la mémoire, il la met dans son pooler interne et attends d'en avoir besoin. Si y en a pas besoin, ben il "libère" la mémoire qu'à la fin du programme !
[EDIT] Toute fois, je n'aime pas ce genre de comportement, qui pousse à la pénurie stupide sur des programmes qui tourne "longtemps".