Fuite mémoire sur composants Indy 9.0.50

Sur BDS2006 les composants clients et serveurs présentent le défault à la fermeture du programme (suivi par Codeguard):

Citation:

---

Erreur 00001. 0x300010 (Thread 0x0890):
Fuite de ressource : le bloc mémoire (0xF45020) n'a jamais été libéré

Le bloc mémoire (0x00F45020) [taille : 28 octets] était alloué avec SysGetMem
Arborescence d'appel :
0x004233C6(=Test.exe:0x01:0223C6) system.pas#2648
0x0048AA42(=Test.exe:0x01:089A42) IdComponent.pas#185
0x004A0BAD(=Test.exe:0x01:09FBAD)
0x004A0D83(=Test.exe:0x01:09FD83)

---

C'est systématique, même si on construit l'objet dynamiquement avec New.

Je sais pas si il n'y a un risque d'impact de type plantage ??? en cours de fonctionnement

Après des dizaines de tests, aucun impact fonctionnel, et en plus c'est pas les seuls composants qui libères mal...:?

aujourd'hui avec RAD 2009, en cours de migration:
toujours fuite de mémoire à la libération mais là ça fait des plantages.
Composant Indy ICMP pour faire un Ping IP su le serveur.
Même avec codeguard j'ai mis deux heures à isoler le truc.. car j'avais oublié ça.

il suffit de mettre juste le composant dans une fiche vierge, de lancer l'appli et de sortir de l'application.. 32 octets de perdus.

sous Delphi 2009, pas de PB...

Savez vous ou je peux signaler cela ??

Le projet indy a une page qui explique ce qu'il faut faire.

http://www.indyproject.org/Sockets/Bugs.EN.aspx

Et Indy 10 est maintenant compatible avec C++Builder (j'ai pu l'installer sur BDS2006 sur les personnalité Delphi et C++) mais il faut faire avec le dépot SVN.

Merci gandf , effectivement ils en parlent, mais pas trouvé de correctif ou mise à jour sur ce sujet...
Si tu as un lien...

Je suis maintenant en RAD2009 et Indy 10.2.5

Le problème est toujours présent avec indy10?

En fait, il doit surement y avoir un lien sur un forum où rapporter le bug sur cette page.
http://www.atozed.com/indy/Newsgroups.en.aspx

Il ne faut pas rapporter de bug sur indy9 sauf problème majeur. Ils ne développent plus que la version 10.

Oui toujours présent sur la version 10...avant c'était 24 octets non libérés maintennat c'est 42...:mrgreen:

c'est invisible sur de petites applications, à part si tu lances Codeguard (que je met toujours en route en phase pré-prod..)

Sur des plus grosse appli.. c'est carément plantage avec debug Windows..
enfin c'est pas propre quoi, vérifiez si vous utiliser Indy en BCB++ ou RAD c'est systématique à la libération des ressources.

J'ai fait un test. Dans un nouveau projet, j'ai posé sur la fiche principal un TIdIcmpClient et j'ai activé toutes les options codeguard. Tout cela dans C++Builder 2006 (BDS2006). Et j'ai lancé l'application.

J'ai ensuite fermé l'application. Aucune erreur ne c'est présentée. J'ai édité le fichier cgl créé par codeguard et il n'y a aucune erreur d'indiquée.

Est-ce la bonne procédure de test? As-tu appliqué le patch #2 sur BDS2006 concernant le compileur ou le lieur qui provoquait des fuites de mémoire dans certaines circonstances?

Oui la procédure est aussi simple que ça et dans le débogueur (EDI) tu vois normalement l'adresse et le nombre d'octets non désalloué.
(vérifie bien que tu es en config déboggage)

En BDS2006 j'étais bien avec les bonne release patch2 et là en RAD2009 aussi et en INDY version livrée avec le RAD c'est à dire Version 10.2.5
(c'est 32octets et non 42 comme j'ai pu dire)

de plus je ne suis pas le seul, mais j'ai un peu de mal avec les forums Indy, le versionning SVN et les groupes de discussions, c'est un peu le "bordel désorganisé"
Tu as quel release Indy?

copie de la fenêtre Message à la fermeture de la fiche principale:

Citation:

---

27/04/2009 19:45:49 démarré un processus CodeGuard(tm) : Project2.exe(6096)
Fuite de ressource en cours de traitement : Project2.exe(6096) - System.pas#3413
le bloc mémoire (0xEA8B38) n'a jamais été libéré
Le bloc mémoire (0x00EA8B38) [taille : 32 octets] était alloué avec SysGetMem
0x00428CFE - System.pas#3413
0x0049A1AF

---

Je confirme, il n'y a pas de fuite de mémoire chez moi. Je n'ai aucun message d'erreur. Par contre, en rajoutant :

Code:

---

1 2 3 4

void __fastcall TForm1::FormCreate(TObject *Sender) { int *i = new int(1); }

---

Il m'indique une fuite de mémoire, ce qui est normal puisque je ne fait pas de delete.

Et toujours aucune fuite de mémoire avec le TIdIcmpClient juste placé sur la fiche.

La version que j'ai compilé est celle dispo sur le svn le 21/04/2009.

Du coup, je n'ai pas de fenêtre message puisqu'il n'y a aucune erreur.

merci pour tes tests Gandf, c'est très gentil à toi.

Je vais voir comment récupérer cette version.

Merci encore

Par contre, c'est une version en cours de développement et certains composants ne sont pas toujours disponible. Par exemple, je n'ai pas les composants supercore et d'autres manques comme TIdICMPServer.

dis voir je ne trouve pas la version dont tu parles, je ne trouve que la version 10.1.1
ici: svn://svn.atozed.com/indy/indy10/tags/Indy 10.1.1
alors que moi je suis en 10.2.5. ??

Non, la version actuelle est dans la branche "trunk" et n'est pas vraiment numéroté en 10.x.x puisque c'est une version de développement. Généralement, ces numéro sont pour les release officielle.

Ici, les numérotation sont en rxxxx. a chaque fois qu'un développeur fait une mise à jour (d'un ou de plusieurs fichiers), cela incrémente le numéro de la rxxxx. Ainsi, même si un bug est apparu et qui empêche certaines partie de la librairie de fonctionner a un moment sur la version de développement, il suffit de récupérer un numéro rxxxx qui fonctionnait.

Avec tortoise SVN, je ne sais pas comment faire pour récupérer le numéro de version. Sous linux, il faut utiliser la ligne de commande svn.

Pour que cette version fonctionne, il faut supprimer les ancien fichiers bpl (dans le dossier bin de bds et dans le dossier system32 de windows).

Ok, merci, je vais voir si je procède à une mise à jour, car cela me paraît un peu périlleux pour moi pour l'instant :mrgreen: cette gestion de référenciel SVN

pour information:

Citation:

---

They are intentional leaks in Indy. You can either ignore them, or you can
read the comments in IdThread.pas and IdStack.pas and recompile Indy to
remove the leaks.

--
Remy Lebeau (TeamB)

---