Discussion :

[smagne-staris]

Bonjour,

J'ai une appli constituée d'un .exe et de dlls différentes. Chez un de mes clients sur un serveur windows 2012 mon appli a un comportement bizarre. les dlls servent à faire des impressions. dans mon appli j'ai une méthode qui est utilisée pour lancer une impression: Elle charge une dll, appel une méthode de la dll pour faire l'édition à proprement parlé et libère la dll.

Chez mon client, quand je charge la dll (par appel de LoadLibray) je vois la mémoire de mon appli augmenter alors que ne n'ai encore appelé aucune fonction. j'appel une méthode qui fait l'impression et je libère la dll (par appel de FreeLibrayry); a ce moment je constate que mémoire n'est pas libérée. Avec processExplorer je constate également que ma dll est toujours chargée. Ce comportement je ne le constate QUE chez ce client sur ce serveur.
Si je relance l'impression, ça recommence : ça charge à nouveau la dll, la mémoire augmente et la dll n'est pas libérée. A ce moment, avec processExplorer je constate que j'ai 2 fois la même dll chargée. C'est vraiment bizarre.

Si quelqu'un a déjà rencontré ce pb et sait comment le résoudre je suis preneur. J'ai fait pas mal de recherche sur le web, mais pour l'instant je n'ai rien trouvé.
Je suis sous Delphi XE3. Sur le serveur en question j'ai un autre prog qui fonctionne sur le même principe, fait avec Delphi XE3 également, mais et je n'ai pas ce pb.

Merci pour votre aide.

[ShaiLeTroll]

Je ne sais plus où j'ai évoqué cela sur le forum, c'est peut-être même en C++Builder

Je me souviens d'un problème d'une Erreur lors du FreeLibrary qui empêchait de libérer la DLL
Comme toi, tout était en chargement dynamique à la volée
Et cela doit remonter à 10 ans, je ne pouvais plus recharger la DLL par la suite ... si je retrouve un truc à ce sujet

J'ai un doute sur la présence d'un code de finalization en échec, soit donc en Delphi, tout code présent dans le DPR et tout code initialization/finalization
En C++ Builder, c'est DllEntryPoint DLL_PROCESS_ATTACH / DLL_PROCESS_DETACH


Edit :

// Les threads doivent être arrêté de préférence dès le Finalize !
// Il semble que durant un FreeLibrary, cela provoque des blocages ?
// Le Problème est que le blocage est tellement aléatoire qu'il est difficile de dire c'est une bonne modification ou juste de la chance ! L'avenir nous le dira !

C'était bien en C++, j'utilisais la même DLL interne dans plusieurs threads, cette DLL en utilisait des DLL d'un tiers qui créent elles aussi des threads
Il fallait bien respecter un certains ordre, appeler une fonction "Cleanup" d'un DLL Tiers (cela coupe les threads de la DLL), arrêter tous les threads qui ont pu utiliser la DLL du tiers et les threads ayant utiliser la DLL interne puis libérer par FreeLibrary le handle de la DLL dans le même thread que celui qui a fait le LoadLibrary
Dans le cas contraire, ce n'était pas un problème de mémoire mais un problème de DeadLock

Donc désolé, ce n'était pas la même situation car dans mon cas c'était un EXE qui utilise une DLL A interne qui utilisait une autre DLL B interne qui utilisait un ensemble de DLL Tiers, la séquence d'arrêt devait être particulièrement soignée.
A savoir que DLL A et DLL B étaient faites par mes soins et invoquées via LoadLibrary/GetProcAddr/FreeLibrary : voir DLL mélange export C et C++
les DLL Tiers étaient liées statiquement (.Lib + .H), donc c'était le soin à apporter au FreeLibrary de DLL B qui importait

[smagne-staris]

Merci ShaiLeTroll pour ton message, je vais regarder de ce coté.
Si d'autres ont d'autres idées, je prends.

[pprem]

Ca ne te le fais que sur ce poste ou tu as constaté ça systématiquement ?

[smagne-staris]

Uniquement sur ce poste. Mon appli est installé sur d'autres postes (sur des windows 10 ou différentes version de vindows server) et ça ne le fait pas.
Par contre, sur ce poste (un windows server 2012 utilisé en TSE) ça le fait systématiquement. Windows est à jour.

C'est bizarre.

[ShaiLeTroll]

le TSE, je ne sais pas mais CITRIX qui se base dessus, en fait lors du changement d'un CITRIX à une nouvelle version CITRIX XenApp (le client est passé de Citrix Online Plug à Citrix Receiver, je ne connais pas les versions mais ça donne l'époque)
au passage, la ferme de servers est passé de Server2008 à Server2012

Au niveau du chargement des EXE, j'ai noté un changement notable : un CACHE
Sur Server2008 + CITRIX époque Citrix Online Plug = Changement de l'Exe sur le Serveur, Mise à jour immédiate (si personne dessus bloquant l'accès au fichier, un système de maj auto qui fonctionnait quasiment jamais et pas synchro selon l'instance serveur choisi selon la charge dans la ferme)
Sur Server2012 + CITRIX époque Citrix Receiver = Changement de l'Exe sur le Serveur, Mise à jour prise en compte qu'au redémarrage hebdomadaire de la Ferme (le système de maj auto ne fonctionnait plus, on avait remplacé cela par une distribution sur un master car au final, les mises à jour en direct n'avait aucun effet si l'exe était lancé par un utilisateur et comme beaucoup fermait pas leur session, plein de chose restait ouverte et cela conservait donc la dernière version présente au moment du premier lancement)

A voir si le chargement de la DLL peut être influencer par le TSE
Car sur un serveur, les utilisateurs ne pouvaient avoir que la version initiale mis en cache
Du coup, on pouvait avoir un serveur de la ferme avec la dernière version car l'EXE était libre et une autre version sur le reste de la ferme, même quand je poussais une mise à jour de force sur un BAT sur l'ensemble des serveurs de la ferme.