), Jesse Ruderman a publié sur son blog un long message explicatif sur les progrès de la suppression des causes des fuites mémoires dans Firefox/Thunderbird/Seamonkey et un rappel sur la manière de contribuer en rapportant une fuite mémoire (quels outils utiliser afin de précisément indiquer d'où vient la fuite mémoire).
http://www.squarefree.com/2006/02/04/me ... k-progress
Je vais résumer autant que possible les principales indications de ce message, mais cela ne pourra être aussi complet que le message original dont je vous recommande la lecture.
Ruderman indique ainsi que dans Firefox 1.5.0.1, comme je vous l'avais indiqué, deux bogues de fuite mémoire sont résolus, des bogues décrits dans les rapport de bogues Bugzilla n°316775 et 317478.
Par ailleurs, dans le tronc ont été résolus depuis la séparation avec la branche 1.5, 10 bogues de fuite mémoire.
Un éclaircissement à ce propos, pour que les questions de branches et troncs soient limpides pour vous.
Ces termes ont la même signification que dans un arbre, à savoir que le tronc pousse, et que surgit au fur et à mesure sur ses flancs des branches.
Ainsi avant la version 1.0 (et ce fut le cas pour les versions 0.x auparavant), le tronc a vu naitre une branche 1.0 sur ses flancs, qui a aboutit à la version 1.0 et à toutes les versions 1.0.x suivantes.
Le développement consistant en l'introduction de nouveautés et la résolution de bogue ou de faille de sécurité s'est poursuivi sur le tronc ; il ne s'arrête à vrai dire jamais, sauf durant quelques jours précédent la naissance d'une branche afin que des changements importants n'ait pas lieu avant la naissance d'une branche. Dans le même temps la branche 1.0 était développée par, contrairement au tronc, uniquement l'introduction de résolution de bogue et faille de sécurité.
Au cours de l'été, la branche 1.5 est née à partir du tronc, identiquement, à partir de cet instant, les destins de la branche et du tronc sont séparés, alors qu'il se confondait jusque là. La branche a été à partir de ce moment de l'été dès lors développée pour aboutir à la sortie de Firefox 1.5 en novembre puis 1.5.0.1 il y a environ une semaine. Le tronc quant à lui dès cet été se dirigeait vers la version 2.0 (dont la branche se séparera du tronc sans doute au début du printemps, après 8 mois de développement du tronc).
Et quelques mois plus tard (cet été probablement) cette branche née au printemps donnera naissance à la version 2.0 (puisque la version finale est en moyenne éditée trois mois après la naissance de la branche).
Pour cette raison, les bogues résolus sur le tronc depuis la séparation avec la branche 1.5, ne sont pas forcément résolus dans la branche 1.5. C'est le cas des 10 fuites de mémoires résolues sur le tronc.
Heureusement, ces corrections sur le tronc vont être appliqués à la branche et seront disponibles selon Jesse Ruderman dans la version 1.5.0.2
Il semble d'après ce dernier que après ces corrections, le tronc (et bientôt donc la branche) ne souffre plus de fuite qui soient sensibles à l'utilisateur.
Par ailleurs Ruderman évoque l'outil de David Baron (leak gauge) pour diagnostiquer précisément la cause de la fuite mémoire. Cet outil jusque là en Perl, existe désormais en javascript (plus facile d'utilisation pour les Windowsien qui contrairement aux utilisateurs de système de type Unix (Mac OS X, Linux, Unix BSD, ou Unix propriétaires) n'ont pas facilement accès à ce langage. D'ailleurs sur les 30 derniers rapports de bogues de fuite mémoire, 19 auteurs de ces rapports ont utilisé cet outil, dont le résultat est bien plus utile qu'un rapport ne contenant qu'une plainte affirmant que le logiciel "utilise beaucoup de mémoire après quelques heures".
En outre la meilleure manière de ne pas rapporter une fuite mémoire qui soit déjà résolue est de tester les versions expérimentales construites à partir du tronc lors de l'usage de cet outil.
Par ailleurs Ruderman évoque dans la suite de son message que les fuites de mémoires ne sont pas toujours dues à Firefox lui-même. Certaines naissent (outre les plugins que j'avais évoqué l'autre fois) parfois d'étourderies dans les extensions. Certes, comme je vous l'ai évoqué, à moins que ce soit des extensions XPCOM (extrêmement rares), les extensions ne sont basés que sur le langage de balise XUL en relation avec du Javascript.. Comment du Javascript pourrait créer des fuites mémoires?
Le Javascript gère d'ordinaire des petits objets (une variable ou un tableau, ou des objets tel qu'une fenêtre ou un bouton de la page) et il est rare, à moins de faire la bêtise de remplir sans fin un tableau en mémoire, de réussir à créer une fuite mémoire. Mais dans le cas de son utilisation dans une extension, le Javascript est étendu, en sus des objets auquel il a accès habituellement, à des objets plus avancés relatifs à l'interface, et une grande partie des fonctions de Firefox/Thunderbird/Seamonkey. Une erreur fréquente est donc d'tiliser un de ces objets, et au lieu de le réutiliser ensuite, d'en créer un nouveau, sans avoir détruit les anciens devenus inutiles. Et contrairement au petits objets gérés par le Javascript, ces objets sont plus gros, et quand un millier de ces objets sont en mémoire (après quelques heures d'utilisation d'une extension mal programmée), la fuite est importante. De telles extensions ne sont de toute façon pas populaire et peu connue et je ne crois pas que vous en utilisiez.
Par contre parfois la fuite peut survenir par le conflit de deux extensions, qui sans que vous le sachiez tentent faire deux choses opposées.
Pour l'une des deux la fonction va échouer, ce qui peut dans certains cas de programmation faire que l'on atteigne pas le point où est détruit un objet (Ruderman n'évoque pas précisément cette explication, mais ayant eu l'occasion de repérer quelques fuites mémoires dans des extensions, j'en connais la cause)
Ainsi la cohabitation de quelques extensions (une dizaine d'entre elle sur le bon millier existant) que Jesse Ruderman évoque brièvement, provoque quelques fuites mémoires. Leurs auteurs ont été contactés afin d'ajouter des vérifications sur l'échec de leurs fonctions (en somme il leur est requis de programmer de façon moins optimiste, sans songer que tout se passe toujours bien)
Je vous renvoie à la note de Jesse Ruderman dans sa longueur pour plus d'information et quelques liens.
Hugues
Mozbackup ne veut rien savoir, je suis coincé 
)
