Nous avons remarqué que lorsqu’un trou est joué, la consommation mémoire de la JVM chez certains se met considérablement à augmenter, passant de 70Mo à 120-150 Mo, provoquant des gros lags dans un premier temps puis au plantage définitif du jeu.

Merci de prévenir, je vais regarder à ça…

J’ai fait quelques tests et j’ai rien remarqué d’anormal… Comme tu le sais peut-être ou peut-être pas, en Java, c’est la machine virtuelle qui s’occupe de nettoyer la mémoire et de supprimer les objets qui doivent être détruit. Quand on lance une machine virtuelle, elle peut prendre une certaine quantité de mémoire pour fonctionner. D’où l’augmentation de mémoire que tu observe, il s’agit d’élément à supprimer mais la machine virtuelle ne les supprime pas parce qu’elle a assez de place pour faire tourner le programme… Je n’ai donc pas remarqué quelque chose lié au trou, mais si tu expérimente encore ces problèmes n’hésite pas à m’en faire part…

Voilà ce que ça a donné chez moi : plantage en règle ! J’ai regardé, java.exe est passé de 60Mo à 4Mo et plus rien 🙁

Ca ne ressemble plus à grand chose… lol C’était aussi après un trou?

À mon avis ce n’est pas lié à un trou… On a eu de nouveau le même bug lors d’une partie, mais pas du tout après un trou. Les symptômes étaient les mêmes: le jeu commence à lagger chez plusieurs joueurs (déplacements de la souris saccadés, cartes qui mettent un temps fou à être jouées), et ensuite un des trois joueurs fini par être « déconnecté » des 3 autres (n’arrive plus à leur parler sur le chat), bien qu’aucun message de déconnexion ou autre ne soit affiché. Comme tu l’as dit, c’est étrange car Java se charge tout seul de libérer les objets, mais il faut quand même faire attention à un point: si des références restent conservées dans une HashMap par exemple, on les oublie parfois… Enfin c’est juste une idée comme ça, car s’il s’agissait « juste » d’une augmentation mémoire, le ralentissement devrait être plus progressif à mon sens :/ Bonne chance dans le chasse au bug !

Stany a été bloqué, nous avons dû quitter 🙁 Dans le chat, nous voyions ce qu’il écrivait, mais lui ne voyait pas ce que nous écrivions.

Et après ce fut mon tour 🙁

Ouais ça m’est arrivé aussi, je cherche le problème mais à priori rien à voir avec les trous…

Bonsoir Thibault 🙂 Je le pense aussi, j’ai activé la console au cas où…

Toujours le même bug, voici le message d’erreur dans ma console Java: (à noter que je n’étais pas celui qui a planté): Exception in thread « Image Fetcher 0 » java.lang.StackOverflowError at java.awt.image.Raster.(Unknown Source) at java.awt.image.WritableRaster.(Unknown Source) at sun.awt.image.SunWritableRaster.(Unknown Source) at sun.awt.image.IntegerComponentRaster.(Unknown Source) at sun.awt.image.IntegerInterleavedRaster.(Unknown Source) at sun.awt.image.IntegerInterleavedRaster.(Unknown Source) at java.awt.image.Raster.createPackedRaster(Unknown Source) at java.awt.image.Raster.createPackedRaster(Unknown Source) at java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source) at sun.awt.image.ImageRepresentation.createBufferedImage(Unknown Source) at sun.awt.image.ImageRepresentation.setPixels(Unknown Source) at java.awt.image.ReplicateScaleFilter.setPixels(Unknown Source) at java.awt.image.ReplicateScaleFilter.setPixels(Unknown Source) at java.awt.image.ReplicateScaleFilter.setPixels(Unknown Source) at java.awt.image.ReplicateScaleFilter.setPixels(Unknown Source) avec la ligne « at java.awt.image.ReplicateScaleFilter.setPixels(Unknown Source) » répétée une bonne centaine de fois :p

Merci LauNch! Je n’avais jamais vu cette erreur, je vais voir ce que ça donne mais à mon avis on tient une piste pour la solution 😛

La correction a été apportée hier soir, vous avez toujours ce problème depuis?