Journal Leakez la mémoire du système avec Win32

Posté par (page perso) .
Tags : aucun
0
16
juil.
2004
Dans une explication-pour-neuneu de WinFX (le remplaçant de l'API Win32 pour Longhorn) pêchée sur osnews[1], on apprend que quand on utilise Win32, "the programmer has to explicitly take care of memory de-allocation, or else when the program exits it will result in memory leaks".

Résumons : le programme quitte, et le résultat c'est un memory leak, donc, dans le système, pas dans le programme, puisque ce dernier a quitté.

Alors, de deux choses l'une, soit le kernel de Windows ne récupère pas la mémoire allouée par un processus qui se termine, ce que j'ai vraiment énormément de mal à croire malgré tout ce qu'on peut penser de Windows, soit l'auteur de cet article n'a vraiment rien compris du tout au fonctionnement d'un OS (allez je cite sa courte bio : Wei-Meng Lee (Microsoft .NET MVP) is a technologist and co-founder of Active Developer, a technology company specializing in hands-on training on the latest technologies. He is an established developer and trainer specializing in .NET and wireless technologies).

J'avoue que je suis sceptique...

[1] http://www.windowsdevcenter.com/pub/a/windows/2004/07/13/winfx.html(...)
  • # t'as raison

    Posté par . Évalué à 10.

    Le gars n'a effectivement rien capte.

    Quand le process meurt(en se terminant, etant tue,...), son espace memoire virtuel est detruit et toutes les pages(ram physique ou swap) sont reprises par le mem manager, meme chose pour toutes les resources qu'il detenait(mutex & autres events, handles,...), il n'y a pas de leak.
    • [^] # Re: t'as raison

      Posté par (page perso) . Évalué à 3.

      Et heureusement, encore...
    • [^] # Re: t'as raison

      Posté par . Évalué à 0.

      Y'avait pas quand même quelques problèmes de gestion de la mémoire dans les anciennes versions de Windows (9x voire 3.1) ?

      J'avoue ne pas avoir eu l'occasion de tester, mais j'ai entendu dire qu'il suffisait de lancer et fermer un logiciel comme Word plusieurs fois pour bouffer toute la mémoire libre.
      • [^] # Re: t'as raison

        Posté par (page perso) . Évalué à 1.

        Bof. Probablement un neuneu qui confondait mémoire libre avec mémoire en cache. Si t'as ni pointeur ni testé toi-même en plus...
      • [^] # Re: t'as raison

        Posté par . Évalué à 3.

        Peut-être le probleme des ressources:
        Des zones de mémoires fixes de 2x64 Ko pour les ressources 16 bits (win 3.x et win 9x) et 3 x 2Mo pour les ressources 32 bits. (win 9x), si ma mémoire est bonne. Certaines applications mal foutus ou réputée grosse consomatrice ( logiciel de dessin, affichage de police, surtout les applis Win16 je crois) et même certains widget ! ( les onglets: il existait des astuces de programmation pour ça). Ça pouvait faire planter le systeme quand il n'y en avait plus, et ceci même si il restait encore des tonnes de mémoire vive !!

        C'etait super impressionnant sous win9x, car la boite de dialogue qui te prevenait quelques secondes avant le BSOD, c'etait une boite de dialogue avec les widgets ( et même les bordures de fenêtre il me semble) de windows 3.x !!

        Ce problème n'a jamais concernait NT par contre.
    • [^] # Re: t'as raison

      Posté par (page perso) . Évalué à 1.

      Peut etre parle t'il de mémoire alloué au système ou à un autre service dans un but précis (par exemple pour utiliser un service quelquonque genre la recherche ou que sais-je) mais qui ne serait pas liée au programme ?
      C'est peut être une connerie enorme que je dis mais bon, à part ca je vois pas ce qu'il peut vouloir dire :-)
      • [^] # Re: t'as raison

        Posté par . Évalué à 4.

        Je confirme, c'est une connerie :+)

        Un processus ne peut pas allouer de la RAM exterieure a son process address space(sauf si t'as un driver avec des ioctl permettant d'allouer de la RAM comme ca, mais le gugus qui fait ca meriterait 2 fortes claques), sinon t'as un denial of service hyper facile a realiser, t'alloues des giga de cette maniere et la machine tombe car le systeme n'a plus d'espace memoire disponible.
    • [^] # Re: t'as raison

      Posté par . Évalué à 0.

      mouai y a quelque temps (~2 ans), quand je laissais touner trop longtemps windows XP (+ d'une semaine), la memoire libre saturait et meme si je fermais toutes les appli ca n'y faissait rien....
      Y avait que le reboot d'efficace.

      Alors peut etre que les leaks sont dans le "windows manager", mais pour le relancer sous windows sans redemarer, c'est comment dire pas evident ....
      • [^] # Re: t'as raison

        Posté par . Évalué à 3.

        Et ici des gens avaient le meme probleme sous Linux, et ils ont realise que c'etait du au driver Nvidia...

        Mon petit doigt me dit que tu ne sais pas d'ou ca vient, tu sais juste que ca se produit mais tu n'as aucune idee de la cause.

        Donc c'est peut-etre XP qui sait, mais niveau probabilite je parierai plutot sur un bug dans qqe chose d'autre, genre service installe par un anti-virus ou autre, driver,...
        • [^] # troll ! ! !

          Posté par . Évalué à 2.

          Et ici des gens avaient le meme probleme sous Linux, et ils ont realise que c'etait du au driver Nvidia...

          et oui! les joies du propriétaire....
      • [^] # Re: t'as raison

        Posté par . Évalué à 0.

        je confirme, pareil sous 2000.

        Au bout de 10jours c'est pas la joie, je peux plus lancer de programmes ...
        • [^] # Re: t'as raison

          Posté par (page perso) . Évalué à 1.

          Perso je me souviens pendant un de mes stages d'avoir vu des programmeurs windev utiliser un truc style freemem pro pour liberer la memoire mal desalouée.
          Meme si il me semble que le probleme etait principalement du a windev j'avais trouvé ca pratique. Sinon ce petit utilitaire avait une fonction qui permettait de liberer (ou au moins d'essayer) la memoire automatiquement a partir du moment ou un certain % etait utilisé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.