Fuite mémoire dans application winform .NET 2.0

Bonjour,

Je travaille actuellement sur une application .net.
J'ai de nombreuses fuites mémoire sur cette applicatif qui fait qu'au bout d'un certain nombre de temps, l'application génére des outofmemory et doit être redémarré.
Je cherche a comprendre pourquoi mes objets qui sont disposer ne sont pas libéré et il semblerait que ceux-ci sont référencé par d'autres objet.
J'ai essayé de tracer cela avec ANT mais j'avour que la, cela dépasse ma compétence.

En refléchissant, je me faisait la réflexion suivante. Dans mon programme, quand je fait un dispose sur mon objet, c'est que pour moi, l'objet n'est plus référencé nulle part. Si ce n'est plus le cas, alors c'est qu'il y a un problème.
J'aurais donc voulu savoir si en débug, quand je met un point d'arrêt sur un dispose, je pouvait obtenir dans VS 2005 tous les objets qui "tienne" mon objet à disposer (et pouvoir remonter ces référence).

Ant me propose bien un graph de dépendance mais j'ai bien du mal à le lire et a comprendre comment régler mon problème.

MErci pour votre aide

Ce que tu voudrais, un graphe de dépendance, c'est ce que fait un produit style Ants.

Regarde cette session des techdays 2012. C'est du XAML, mais le principe y est :
http://www.microsoft.com/france/mste...id=pMmlNmxQSl9

Une piste peut-être.

Un objet disposé mais qui accueillait un évènement à déclenchement cyclique, comme dans le cas, par exemple, d'une Form qui contient un timer, il faut bien faire attention à arrêter le timer (et éventuellement désabonner l'évènement du timer bien que ce ne soit pas obligatoire si le timer est correctement arrêté) avant de disposer la Form. Car sinon, le timer tournant dans un autre thread, de disposer la Form ne tue pas le timer. Celui-ci continue de tourner et au déclenchement suivant de l'évènement, celui-ci part dans le néant et surtout dans une zone mémoire qui ne lui est plus alloué.

J'ai aussi eu ce genre de corruption dans un cas similaire au timer. Un objet créant un thread annexe, ce thread étant suspendu en attente d'une action extérieur. Entre-temps, l'objet est détruit sans destruction du thread. Résultat, lorsque l'action extérieure intervient, réveillant le thread (ou lorsque le thread se termine après avoir été réveillé, j'ai pas pu le déterminer précisément), plantage !

Bonjour, merci pour vos réponse.
J'ai bien compris que mon objet pouvait-être retenu par une référence externe (handler, timer, etc...). Comme je le disais, j'ai bien les graphes de dépendances avec ant mais j'ai bien du mal à les analyser.

Aussi, je me disait, en debug, quand je suis sur un objet, je peux afficher l'ensemble de ces propriétés enfants (list, objet référencé, etc...).
J'aimerais, toujours en debug, pouvoir faire l'inverse, c'est à dire, à partir d'un objet, avoir tous les objets qui le référence...
Est ce possible en debug ?

MErci

Citation:

---

au bout d'un certain nombre de temps, l'application génére des outofmemory

---

Comme il arrive que le garbage collector ne fasse pas toujours son boulot quand on en aurait besoin, est-ce que la fuite mémoire est réelle, c.a.d visible dans l'onglet performance du gestionnaires de tâches (lancé via CTRL/ALT/SUPPR)?

Pour limiter ces problèmes de garbage collector, on peut exécuter cette procédure pour forcer le garbage collector à bosser (par exemple si un programme traite une liste de pays, on pourra appeler cette procédure dès que le traitement d'un pays est terminé).

Code:

---

1 2 3 4 5 6 7

internal static void CollectGarbage(int SizeToAllocateInMo) { long [,] TheArray ; try { TheArray =new long[SizeToAllocateInMo,125000]; } catch { TheArray=null ; GC.Collect() ; GC.WaitForPendingFinalizers() ; GC.Collect() ; } TheArray=null ; }

---

Comme l'appel à GCCollect est pénaalisant, cette procédure n'y fait appel qu'en cas de réelle necessité.

La piste proposée par Sevyc64 est à vérifier. C'est ce qui est arrivé aujourd'hui même à un collègue :cfou:.
Il s'agissait d'une form avec un timer dont l'event Click était géré par un objet qu'on allouait/libérait/recréait sans désabonner le timer à l'event. Ainsi, les objets n'étaient jamais désalloués car toujours référencés par l'event click du timer de la form.

Citation:

---

Envoyé par olysmar

J'aimerais, toujours en debug, pouvoir faire l'inverse, c'est à dire, à partir d'un objet, avoir tous les objets qui le référence...
Est ce possible en debug ?

MErci

---

Je ne pense que ce soit possible, mais c'est une idée très intéressante à soumettre aux développeurs Microsoft. (J'ai quand même un doute, je me demande s'il n'y a pas des API du framework qui le permettent, donc par programmation).

Dans la même situation, je devais débuguer un programme C#. Ne pouvant assimilier le code en une journée, j'ai tenté ma chance avec winDebug.

Ben, avec cet outil tu sais qu'il y a un bug mais c'est incompréhensible. Bref seule la revue de code (au bout d'un mois) a permis de corriger les bugs.

De mon expérience, les outils gratuits ne m'ont pas aidé à corriger des bugs. Je n'ai pas testé d'outils payants.

Pour répondre a graffito, je ne pense pas que cela soit un problème de garbage (le process monte dans le gestionnaire de tache).
La monter en mémoire se fait peu et bloque au bout d'environ 4 heures.

Je pense simplement que j'ai du mal a enlever toutes les références et que du coup, mes objets reste en l'air

Merci pour votre aide