Bonjour,

Je pense avoir détecter une fuite de mémoire dans un bout de code de mon application.
Je l'ai récupéré et remis dans une appli "vierge". J'ai une form dans laquelle j'ai 4 labels, un tooltip et un timer puis un module public dans lequel j'ai une enumération.
Le code est le suivant :
Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick
        Dim alarm As _AlarmEnum
        Dim i As Integer

        Timer1.Stop()
       
        Try
            For i = 0 To 3
                alarm = CType(1, _AlarmEnum)

                tooltip1.SetToolTip(label_alarm_code(i), alarm.ToString)

                If alarm <> _AlarmEnum.ErrNone Then
                    label_alarm_code(i).BackColor = Color.Red
                Else
                    label_alarm_code(i).BackColor = Color.Black
                End If

            Next

        Finally
            Timer1.Start()
        End Try
    End Sub

Rien de bien sorcier et pourtant quand je lance mon .exe, l'utilisation de la mémoire est à 10MB et après une nuit (on va dire 10H), l'utilisation de la mémoire est passé à 70MB et elle ne stabilise toujours pas!
Comme dans ma "vraie" appli, j'ai plusieurs fois ce bout de code, au bout d'une nuit, l'appli est plantée, il faut la fermer pour libérer les ressources (pas terrible pour de la prod). J'ai déjà essayer de forcer le garbage collector, mes objets semblent finalisés...
J'étais en vb2003, je suis passé en vb2005 express rien n'y fait. J'ai essayé sur 3 PC différents (XP pro et NT).
Quelqu'un a une idée ?
Et une autre petite question, comment on passe en mode release sur VB2005, sur VB2003 pas de soucis mais sur 2005 je ne trouve pas (Projet/Propriétés de l'appli/compiler-débobguer....??) Pour info j'étais en mode release sous vb2003 mais c'est pareil.

Merci d'avance et bonne continuation à tous!
Nico

salut,

(je ne fais pas de dotnet)

try finally?
finally c'est pas en delphi?

(de lecture) il te faudrait un catch, si tu ne relèves pas l'exception, possible qu'il y ait un problème à ce niveau...

quel est l'intervalle de ton timer?
que contient ton enum?
est-ce vraiment (selon l'intervalle) la peine d'arrêter et de relancer ton timer?... voilà bien une action extrêmement gourmande!

alarm = CType(1, _AlarmEnum)
puisque pas i, pourquoi ne pas le faire avant la boucle?

enfin ta gestion d'erreur (peu importe la syntaxe), quel cas de figure peut te mettre en erreur sur 3 lignes?

++

---

Prenez un instant pour répondre à ce sondage svp  

Oui,

Il me semble que c'est un problème de conception de ta part.

Tu ne sais pas utiliser un timer.

Je ne vois pas pourquoi tu demerre et arrete le timer dans le traitement de ce meme timer.

De ce que je sais c'est.
Sur action ou evenements tu rends enabled un timer sur un interval t par exemple.

Et dans le tick tu travailles. --Do work comme disent les anglais.

Ensuite sur un autre evenement ou action si nécessaire tu arretes le timer.

Mais evites de travailler sur le timer dans son traitement, je n'en vois pas l'intéret.

Bon coding

Pourquoi arreter et relancer le timer au début et à la fin de ta procedure, laisse-le tourner tranquillement et faire sont boulot.

Ensuite je dirais qu'à priori ton problème ne vient pas de ce bout de code. Il ne semble pas y avoir de source fuite mémoire dans ce code


---- Sevyc64  (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #    [ Lien ]

Bonjour à vous,
merci pour votre aide.

Alors pour commencer :
- le "catch" existe dans mon code réel, mais il n'y a pas d'exception dans ce bout de code.
- L'intervalle de mon timer est de 200ms.
- Mon enum contient les textes de mes alarmes. En fait je récupère un code alarme depuis une carte électronique.
   Public Enum _AlarmEnum
        al0 = 0
        al1 = 1
        al2 = 2
        ErrNone = 3
    End Enum
- alarm = CType(1, _AlarmEnum)
puisque pas i, pourquoi ne pas le faire avant la boucle?
Effectivement, dans ma vraie appli j'ai une variable qui est indexé par "i", voilà pourquoi je l'ai laissé dans la boucle.

- Ce timer est toujours enabled dans mon appli. J'ai un start et un stop car dans ma vraie appli je lance un thread qui récupère les données de ma carte (gestion d'un port com...) et il m'est arrivé d'avoir un chevauchement. Je pourrais effectivement enlever le start et le stop et augmenter l'intervalle du timer. Mais cela ne change pas le pb.
Bref, admettons, je supprime le start et stop du timer....
J'ai toujours le problème.
Je répète que mon bout de code est un code "batard" qui comme cela ne correspond à rien. C'est juste pour montrer que j'ai une fuite juste avec ça.
Est ce cette fuite peut venir du tooltip ? Je ne vois pas pourquoi ? mais....
Merci encore pour votre participation.

Bonjour casy,
Je crois qu'on a posté en même temps.
Pour te répondre : le timer j'explique ci dessus.
Si le problème ne vient pas de ce bout de code, je ne comprends pas ce qui peut jouer sur le processus de mon appli. J'ai testé plusieurs PC, VB2003/VB2005, mode release/mode debug...
Quel autre paramètre peut provoquer une fuite de mémoire ?

Merci

Salut,

Je crois savoir quel est ton problème, même si cela contredit ton "Pour info j'étais en mode release sous vb2003 mais c'est pareil."

http://www.vbfrance.com/infomsg_VB-NET-FUITE-MEMOIRE_1134526.aspx
Mon dernier message => lien contient la réponse.

"J'ai donc mis l'évènement MouseEnter sur mes labels et je fais intervenir le tooltip dans cet évènement. Je n'ai plus de fuite de mémoire."

A mon avis ta fuite est toujours là, simplement que tu ne fais plus l'opération 4 fois toutes les 200ms, et donc l'augmentation de la mémoire est beaucoup plus faible.

Salut Kevin,

J'avais déjà lu tes réponses avec tout ce qui s'en suit : lien forum microsoft et msdn... J'ai cru alors être délivré de ce lourd fardeau,
je croyais alors avoir résolu mon problème et pourtant cela n'a rien changé!!!
Sais tu comment on compile en mode release sur VB2005 express ?
Je ne trouve pas dans les propriétés de l'appli contrairement à VB2003.
Merci