Discussion :

[29kiteman]

Salut à tous,

Je viens de passer quelques lonnngggues heures sur un problème de memory leak, et semble l'avoir "résolu", d'une manière logique mais surprenante... J'aimerais avoir votre point de vue sur ce problème.

Contexte :

- framework .Net 1.1
- une appli qui charge une centaine de composants maisons "B" dans un panel "A".
- les fonctionnalités de l'appli amènent à vider ce panel A pour le remplir avec d'autres composants B pour rafraichir les datas.

- pour vider mon panel A je faisais un simple A.controls.clear
==> Constat #1 : après ce clear, aucune baisse de la mémoire consommée.

- j'ai donc procédé autrement : while A.controls.count>0 : A.controls(0).dispose
==> Constat #2 : pas mieux

... je vous passe les autres tentatives de GC.Collect, etc...

A coup de débug, j'ai fini par comprendre que certains objets (Tooltip et Timer) de B n'étaient pas libérés par les B.Dispose.

J'ai donc résolu mon problème en :
1> déclarant Private à la classe B tous ces objets Timer et ToolTip
2> overloadant le Dispose de B afin et d'y libérer à la mano les objets Timer et ToolTip ci-dessus...
3> faisant donc un while A.controls.count>0 : A.controls(0).dispose

Et là ça marche ! Plus aucune fuite

Mais je suis surpris que :
- le A.controls.clear ne libère pas naturellement de la mémoire les controls B supprimés (les B.Dispose ne sont pas appelés)
- le B.dispose ne libère pas naturellement les objets Timer et Tooltip créés par B

Votre avis ? Y' a t'il qqle chose que m'échappe dans ce framework...?

[smyley]

La fonction Dispose ne libère pas toutes les resources contenues dans une classe. ça sert à justement libérer ce qui n'est pas du .NET. Si par exemple tu utilises des pointeurs vers des objets natifs, dispose devrais les libérer, mais si une classe a des membres et que tu appelles dispose, rien ne dit que les membres seront à leurs tour disposés à moins que tu overrides dispose.

Ensuite, en .NET un objet n'est jamais supprimé s'il existe une référence vers lui accessible à partir de quelque part d'autre. Donc si tu tiens une référence vers un tooltip qui lui contient des références vers des contrôles et que tu ne supprimes pas le tooltip, la mémoire des contrôles ne sera pas collectée (ceci dit, je ne sais pas comment fonctionne le tooltip).

Autre chose ... pourquoi donc une centaine de contrôles ?!

[29kiteman]

Autre chose ... pourquoi donc une centaine de contrôles ?!

euhhh.... là je sais pas trop quoi répondre ! Disons que j'suis assez fan du Panel
Là en l'occurence je dois présenter les enr. de ma base de données d'une façon assez "riche" ! L'utilisation d'un datagrid me semble parfois insuffisante pour atteindre mes objectifs en terme d'ihm.

Sinon ok pour ton explication pour Dispose. Cela dit les tooltip/timer auxquels je fais référence sont des membres de ma classe, et ne sont en aucun cas référencés ailleurs. Il est donc anormal qu'ils ne soient pas détruits par le Dispose non ?

J'ai pitète une idée.... (la nuit porte conseil !). Les constructeurs du tooltip/timer peuvent prendre en param un IContainer que je ne renseigne pas ! En absence de ce dernier la portée des mes tooltip/timer est peut être étendue au délà de ma classe ! A vérifier...

[Pol63]

je viens de tester de créer 5k boutons sur un panel (augmentation de 10Mo à 20Mo de ram)
puis de faire un panel.controls.clear puis gc.collect
le tout sur le framework 3.5 (clr du fx2 à priori)

en debug ca bouge pas d'un iota
et en release ca retombe à 17Mo
donc il en manque


m'enfin c'est pas bien grave
lol


que ca redescende pas sur le panel.controls.clear c'est normal, gc.Collect est appelé par windows quand y a plus trop de ram dispo, tant qu'il y en a il bouge pas trop (aussi appelé en cas de desctructions de beaucoup d'objets il me semble)


je re regarderais ptete à tete reposé voir de quoi ca vient, car tous les tests que j'avais fait jusqu'à présent montrais que ca se passait plutot bien
et puis on a des applis en place qui doivent fonctionner 24/24 et y a pas de crash style outofmemory ...

[29kiteman]

m'enfin c'est pas bien grave

Ben si c'est grâve !

[nikoko34]

Bonjour,

Pour expérimenter pas mal de manip sur les controles (mais en framework 2), il y a clairement une différence entre les controles non visuels (ceux que tu décris et qui apparaissent à base de la form au lieu d'être dans cette form) et les controles visuels ayant une 'position' dans la form.

Ainsi le ToolStripMenuItem n'est pas considéré comme étant un control de la form (objet d'un de mes posts récents sur ce même forum).

Du coup, le IContainer semble être une bonne voie si tu veux bien faire du ménage dans ta mémoire.