comment débuguer des fuites de mémoire (memory leak) ?

[Golfy]

graph100, tu es trop fort !

j'étais hors ligne cet après-midi mais j'avais vu mon erreur sur la gestion des évènements (et du temps).
Par contre, impossible de voir un delta dans le code que tu as publié (pour autant, ton EXE marche bien) : est-ce parce que je compile/run (avec debugueur) ?

Ton graphe est excellent et maintenant, je trouve que l'outil a vraiment l'air sympa... (juste un peu déçu de ne pas l'avoir réalisé mais de toute façon, je n'aurais pas fait un graphique aussi efficient ).

MERCI POUR TON AIDE, je pensais à terme le publier en freeware (toujours possible si je fais un système graphique ou bien si tu accordes la publication avec ton nom cité) sur le site logitheque.fr ou un truc comme ça... mais déjà, il devrait aider pas mal de développeurs.
Dans mon cas, j'ai un programme sur lequel tester le Leak Finder

PS: quand je vois ton niveau de programmation, ça me "scotche" ! j'ai largement de quoi progresser
PPS : le code généré sur la gestion des évènements est celui du nouveau Form Designer (ou visual designer)

[Edit] et voilà le résultat : un allocatememory de 4096 oct. à chaque scan de mon programme domotique. Merci encore graph100

[graph100]

Par contre, impossible de voir un delta dans le code que tu as publié (pour autant, ton EXE marche bien) : est-ce parce que je compile/run (avec debugueur) ?

Le code posté ne fonctionne pas ?
Chez moi ça tourne bien, j'ai win 7 pro x64, mais je compile avec PB 5.00 32 bit.

Je viens de tester avec PB 5.00 x64, et ça ne fonctionne pas ... Je ne vois pas trop pourquoi, il faudrait vérifier sur msdn si la structure est la même ou bien si l'appel de fonction est correct. (je n'ai pas le temps là)
Donc si tu veux que ça fonctionne sans soucis compile normalement en 32bit, c'est d'ailleurs sans doute pour ça que tu n'arrivais pas à faire fonctionner les autre codes.

Si tu veux publier le programme il n'y a pas de soucis, fait juste référence au code que tu as utilisé de ma part
Par contre, le programme n'est pas vraiment fini, ni publiable en l'état... Je pense notamment au graphique qui n'a pas de barres de défilement. C'est un gadget que je n'ai pas encore fini pour cause de manque de temps (et puis "légende de test X", ça le fait pas )
Du coup si on monitore trop longtemps on n'y vois plus rien...

Enfin, comme les données que tu dois afficher sont "connues", je veux dire que tu sais qu'elle sont positives, et que tu les affiches en fonction du temps, il est moins difficile de faire un affichage par graphe.
De plus actuellement le code redimensionne le tableau à chaque fois, et c’est pas vraiment une bonne solution.

Tu peux aussi sauver le log dans un fichier, etc ...

poste le programme une fois finalisé , j'en serais un des premiers utilisateurs.


ps : j'ai constaté des comportements bizarre sur l'utilisation de la mémoire lors du redimensionnement d'un programme ou du déplacement long et rapide d'une fenêtre. Je ne sais pas si c'est du à windows, mais c'est pas vraiment optimisé en tout cas !

ps2 : si tu fais des modifications dans l'include du graphicgadget(), je serais très intéressé pour les récupérer

[Golfy]

En effet, en compilant en x86 ça marche (y compris mon code)

Bon pour le graphe, je vais voir : j'avais un besoin pour un autre programme et je voulais un système ré-utilisable... donc je vais effectivement revoir cette partie.

Ceci étant, si je publie, c'est bien entendu en faisant référence à ton code et ton nom : tu as fait progresser ce bout de code en un programme presque terminé

Enfin, j'ai aussi remarqué des pertes de mémoire simplement en ouvrant/fermant un MessageRequester() : à suivre (peut-être qu'il faudra passer notre soft à Fred pour qu'il debogue PureBasic ou alors l'envoyer à Steve Balmer de Microsoft )

[graph100]

Il faut regarder la signification de chacun des champs de la structure qui donne les infos sur la ram utilisée.
Ca se trouve il faut combiner avec un autre champs pour avoir la vrai utilisation (un des codes faisait ça je crois)