FastMM configuration avec dll en ShareMem et link avec runtime library

Bonjour,

Je suis sur un projet Delphi 10 qui connait de gros problèmes de fuites mémoire. J'essaie depuis quelques temps d'utiliser FastMM sur le projet pour logguer les fuites dans un fichier sans succès.
En fait cette application est constituée d'un executable qui charge dynamiquement un une bonne dizaine de dll (qui font également partie du projet). Les dlls en question sont toutes en sharemem.
Par contre je m'y perd dans la configuration à utiliser dans ce cas de figure. Quelles sont les options de compilation à utiliser sur l'ensemble des projets (appli et dlls)? Quelles sont les options à mettre dans le fichier de config de FastMM (FastMM4Options.inc)? Quelles dlls à déployer?
J'ai essayé pas mal de configurations sans succès.

Si quelqu'un s'est déjà trouvé dans ce cas de figure et est parvenu à faire fonctionner fastMM dans ce cas, ça m'intéresse.

Merci

Delphi 10 ? Berlin ?
Il inclus une version lite de FastMM
Dommage d'utiliser ShareMem pour un projet D10 alors qu'il existe SimpleShareMem

commence par ajouter cela dans le DPR à la fin

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

... Application.Run;   {$IFDEF DEBUG} {$WARN SYMBOL_PLATFORM OFF} System.ReportMemoryLeaksOnShutdown := DebugHook <> 0; {$WARN SYMBOL_PLATFORM ON} {$ELSE DEBUG} System.ReportMemoryLeaksOnShutdown := False; {$ENDIF DEBUG} end.

---

Faire cohabiter ShareMem donc BorlndMM.dll et FastMM,
euh ... pas terrible, faudrait en théorie le remplacer par FastShareMem

Je viens de le faire mais ça ne donne rien du tout.
C'est quoi la différence entre SimpleShareMem et ShareMem?

Citation:

---

Envoyé par ShaiLeTroll

Delphi 10 ? Berlin ?
Il inclus une version lite de FastMM
Dommage d'utiliser ShareMem pour un projet D10 alors qu'il existe SimpleShareMem

commence par ajouter cela dans le DPR à la fin

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

... Application.Run;   {$IFDEF DEBUG} {$WARN SYMBOL_PLATFORM OFF} System.ReportMemoryLeaksOnShutdown := DebugHook <> 0; {$WARN SYMBOL_PLATFORM ON} {$ELSE DEBUG} System.ReportMemoryLeaksOnShutdown := False; {$ENDIF DEBUG} end.

---

Faire cohabiter ShareMem donc BorlndMM.dll et FastMM,
euh ... pas terrible, faudrait en théorie le remplacer par FastShareMem

---

SimpleShareMem et ShareMem?
c'écrit là : Partage de la mémoire

Citation:

---

Pour utiliser ShareMem
1. Listez ShareMem comme la première unité du programme et de la clause uses de la bibliothèque. Vos modules deviendront dépendants de la bibliothèque externe BORLNDMM.DLL, ce qui leur permet de partager dynamiquement la mémoire allouée.
2. Déployez BORLNDMM.DLL avec votre application ou DLL qui utilise ShareMem. Quand une application ou une DLL utilise ShareMem, son gestionnaire de mémoire est remplacé par celui contenu dans BORLNDMM.DLL.

Pour utiliser SimpleShareMem
1. Listez SimpleShareMem comme la première unité du programme et clause uses de la bibliothèque dans chacun de vos modules. Le module initialisé en premier sera le module qui partagera son gestionnaire de mémoire. Tous les modules initialisés après utiliseront le gestionnaire de mémoire du premier module.
2. Le module initialisé en premier sera le module qui partagera son gestionnaire de mémoire. Tous les modules initialisés après utiliseront le gestionnaire de mémoire du premier module.

---

Oui ok merci ;-) j'avais lu ça.
Mais il ne faut pas que mes DLL soient liées statiquement à l'application pour utiliser SimpleShareMem?
Sinon en fait la seule différence c'est qu'on n'a plus besoin de déployer la dll BORLNDMM.DLL, dans ce cas quel est l'intérêt d'utiliser encore ShareMem?

Citation:

---

Envoyé par ShaiLeTroll

SimpleShareMem et ShareMem?
c'écrit là : Partage de la mémoire

---

Pour moi, ShareMem, FastShareMem ou SimpleShareMem, c'est pour échanger directement des objets et des strings
J'avoue que j'ai toujours fait en sorte de le ne pas le faire en utilisant du PChar ou alors en créant des interfaces comme si c'était du COM mais sans la partie RegSvr ni le TLB et toujours avec des BSTR
C'est aussi pour cela que je n'ai que très rarement des fuites mémoires, je suis un parano à ce sujet, je suis très très rigoureux sur la maitrise des allocations et libérations

Pour le linkage statique, je ne peux pas te dire, je n'en ai jamais fait pour mes propres DLL, je n'aime pas le lien statique,
je préfère gérer mes DLL comme des plugins avec une base commune pour faciliter le déploiement, l'intégration ...
En fait, je ne fais du linkage statique que pour les API Windows et jamais pour aucune autre DLL

Le mieux, c'est d'essayer soit même de faire un EXE et une DLL compilé avec SimpleShareMem et lié dynamiquement avec LoadLibrary\GetProcAdress
Et en fait, c'est même l'exemple fourni sans la Doc RTL.SimpleShareMem Sample et l'on a la réponse puisque l'exemple utilise LoadLibrary



Je pense que ShareMem est là pour un rétrocompatibilité mais pas pour de nouveaux projets

OK merci beaucoup pour ces infos.
Moi aussi en règle générale je fait super attention à la gestion de la mémoire, mais dans le cas présent je me récupère une application existante truffée de fuites mémoire et j'essaie de cerner les problèmes, d'où l'utilisation de fastMM.