Discussion :

[MaelstroeM]

Hello,

Voila j'ai créé un user contrôle (ProgressViewer) tout bête composé d'une progressbar et d'un label. Il n'y a même pas de code dedans.

Ensuite dans ma form j'utilise un FlowlayoutPanel pour ajout/suprimer des intances de ce contrôle. Visuelement on a qq chose qui ressemble à l'interface de emule.

Voici comment j'ajoute les ProgressViewer :
Le FlowLayoutPanel s'appelle "tlpThread"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
        Try
            Dim PgRep As New ProgressViewer
 
            PgRep.Name = "Rep" & TaskId
            PgRep.lblTaskName.Text = TaskId
            PgRep.Tag = TaskId
            PgRep.Width = 737
            Me.tlpThread.Controls.Add(PgRep)
        Catch ex As Exception
           LogException(ex)
        End Try

Et voici comment je les enléve :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

            Me.tlpThread.Controls.RemoveByKey(("Rep" & TaskId))

Bref Rien de méchant.
Pour tester tout ça je laisse tourner l'appli toute la nuit.
Et bout de 6h moulinage (ce qui represente environs 3000 ajout/suppression de controle dans le FlowLayoutPanel)... Paf !!!

Le Me.tlpThread.Controls.Add(PgRep) plante avec l'exception :

EXCEPTION TYPE : System.ComponentModel.Win32Exception
EXCEPTION MESSAGE : Erreur lors de la création d'un handle de fenêtre.

Celle erreur est loggée dans la gestion d'erreur et ensuite j'en prends une autre du même type mais celle ci non géré puisqu'elle arrive dans un obscur fichier :

"TestAppli.My.MyApplication.Main(String[] Args) dans 17d14f5c-a337-4978-8281-53493378c1071.vb:ligne 81" que je n'ai pas dans mon projet
(j'ai trouvé ça dans la StackTrace)

Voilà j'aimerais comprendre pourquoi tout d'un coup le conteneur à craquer nerveusement.
Est ce que j'utilise une mauvaise méthode pour les supprimer ?
Est ce que au bout de 3000 ajout/suppression c'est "normale" qu'il patauge ?

Je pense bien à une fuite de mémoire (car la mémoire utilisée avait aussi tendance à augmenter petit à petit avec le tps)... mais où ?

Si vous avez des idées je suis preneur.
Merci de votre aide

[MaelstroeM]

Manifestement le pb vient du composant lui même,
On peut facilement reproduire le bug.
Il suffit de placer un FlowLayoutPanel sur une Form et d'ajouter un bouton.
Sur code du bouton on met un truc style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
        Dim I As Integer
 
        Try
 
            For I = 1 To 10000
 
                Dim Controle1 As New ProgressBar
 
                Controle1.Name = "Controle1"
 
                Me.FlowLayoutPanel1.Controls.Add(Controle1)
                Application.DoEvents()
 
                Me.FlowLayoutPanel1.Controls.RemoveByKey("Controle1")
 
            Next
 
        Catch Ex As Exception
            Debug.Print(I)
            Debug.Print(Ex.Message)
        End Try

Et arrivé à I +/- = 9959 on a une exception :
Une exception de première chance de type 'System.ComponentModel.Win32Exception' s'est produite dans System.Windows.Forms.dll
Erreur lors de la création d'un handle de fenêtre.

Le pire c'est qu'ensuite le FlowLayoutPanel est hors service, si on appuie à nouveau sur le bouton, ça plante direct avec la même erreur...

Je pense que la fuite de mémoire se trouve bien là :
Au lancement l'appli fait 12 Mo, au plantage on fini à 30.

D'ailleur depuis que j'ai viré ça de l'appli je n'ai plus de fuite.

Par contre je n'ai pas de solution au problème...

[Pol63]

est ce que tu fais bien un Dispose sur tes objets quand tu t'en sers plus
car c'est bien gentil de faire une boucle de new mais faut penser à détruire ...

sinon ca pourrait etre normal que ca plante vu qu'il y a des limites un peu partout et différentes selons les OS
comme le nombre d'objets graphiques par exemple qui est limité, le nombre de handle doit l'etre aussi

essaie de refaire les meme tests avec GC.collect dans la boucle

[MaelstroeM]

Effectivement c'est ce que j'ai testé juste aprés avec un dispose ça marche.
Je ne l'avais pas fait car je pensais que le GC s'occupait de nettoyer les objets quand ils n'étaient plus référencés.

Avec ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
                Me.FlowLayoutPanel1.Controls.Item("Controle1").Dispose()
                Debug.Print(I)
                Me.FlowLayoutPanel1.Controls.RemoveByKey("Controle1")

Je suis à I = 67987 et ça tient toujours.

Ca c'est un bout de code de test "violent" dans l'appli d'origine les permutations se sont étalées sur 6h... et le GC n'aurait jamais rien fait.

Etrange quand même. non ?

[Pol63]

le GC fait un peu ce qu'il veut et pas forcément bien ...

plus j'en découvre sur .NET plus je trouve que c'est un peu limite sur beaucoup de choses

[MaelstroeM]

C'est quand même pas évident de penser du premier coup qu'il faut faire le Dispose avant le Remove...
Une chance que le Remove fonctionne toujours aprés ça !!!

Là je viens de faire 100 000 ajouts/suppressions et ca a tenue le choc.
Plus de fuite de mémoire non plus.

Bon je vais reimplementer tout ça dans l'appli d'origine et voir si ça tien la route.

Merci de ton aide... je me sentais un peu seul !

@ Suivre

[Pol63]

j'ai des problèmes avec les dipose aussi
c'est un peu mal pensé leur système

[MaelstroeM]

J'ai remarqué qu'utiliser un Bloc Using/End Using simplifie les choses et évite les oublis de Dispose "malheureux"...
Là le Dispose est garanti quelque soit la façon de sortir du Bloc.