Discussion :

[Slyteck]

Bonjour à tous,
Je vais tâcher d'expliquer clairement mon problème.
J'ai un service windows développé en Delphi qui inspecte une table.
Quand il y trouve une ligne, il lance une Dll (développée aussi en Delphi) qui utilise les données pour imprimer une édition Crystal. Une fois l'édition terminée, le service libère la dll et attend la prochaine ligne.
Mon problème étant que le service qui lance la dll ne meurt pas, et pire, son process monte à 100% de CPU. J'ai pu tracer que c'est au FreeLibrary(dll) que mon service se plante...

Quelques explications subsidiaires :
J'ai migré cette Dll d'une connexion SQLinks vers ODBC, en utilisant le même composant BDE : TDataBase. Je précise cela car avec SQLinks, je n'ai pas de souci. Je n'ai le problème qu'avec une version de cette dll qui passe par l'ODBC.

Mes pistes envisagées :
Les 2 versions de Dll sont vraiment quasi identique, en tout cas dans leur fermeture, rien n'a changé. L'une fonctionne et pas l'autre.
Je pense donc que c'est vraiment liée à l'ODBC, ce qui empêche le service de libérer la dll correctement...

Quelques détails sur mon environnement :
dll et service développé en Delphi 5
Base de données : Informix
Driver de connexion fourni par OLEDB
Plateforme Windows 2008 server

Que dire de plus ? J'espère avoir été clair.

[ShaiLeTroll]

Tu arrives à lancer une édition Crystal depuis un Service Windows sous Windows 2008 Server, cela ne pose de problème d'interaction avec le bureau ?

Tu utilise encore le BDE ? C'est obsolète depuis 10 ans !
Il faudrait passer en ADO si tu veux exploiter ODBC, ou même un OLEDB en direct, dans un service, tu n'as pas besoin de DataSet et de DBControls, la couche d'accès API sera bien plus performante !

as-tu fourni une session à ton service via SC.exe ?
Le comportement du Service change vraiment entre mode SYSTEM et un mode SESSION

tient un sujet de fulster, un ancien collègue qui avait eu ce problème

[Slyteck]

Je suis précisément en pleine migration BDE vers ADO. Et cette dll fait partie de la prochaine étape.
Mais dans l'attente, pour la compatibilité, j'ai migré cette dll en ODBC.
Le service n'a pas de composant Dataset ou DBControls. Il lance la dll avec des paramètres, qui elle, contient les composants.
Et oui, le service est lancé en mode session. Sur celle de l'administrateur qui plus est. Donc à priori, pas de souci de droit d'accès...

[ShaiLeTroll]

Mais dans l'attente, pour la compatibilité, j'ai migré cette dll en ODBC.

C'est quoi en ODBC ? Tu veux dire utilisation directe avec OLEDB ?

Pense au Coinitialize et CoUninitialize si tu utilises des objets COM de l'ODBC, ces fonctions devant être lancer dans le LoadLibrary et FreeLibrary !

J'ai récemment développé des DLL, plus en 1 an qu'en 10, j'ai constaté des problèmes liés aux Threads lancés DANS une DLL (ou sous DLL en liaison statique C++Builder), il semble que soit préférable de les arrêter avant le FreeLibrary, d'ailleurs bcp de DLL tiers fonctionne aussi avec des fonctions Initialize et Cleanup, j'ai procéder de la même façon !
J'avais comme toi, une consommation processeurs ou une sorte de DeadLock, les threads ayant du mal a s'arrêter !
Par contre, l'appelant était un EXE !

Je parle bien de threads créés dans la DLL, j'avais plutôt pratiquer des thread créés dans l'EXE utilisant simultanément la même DLL, là il n'y a pas de problème !

Sous Server 2008, même avec un mode SESSION, j'ai constaté de grosse limitation sur l'interactivité avec le bureau par exemple (ShellExecute ou CreateProcess)

Tu es en 32 ou 64Bits ?

[Slyteck]

Le driver que j'utilise est le suivant : IBM INFORMIX ODBC DRIVER (fourni par OLEDB).

Et pour répondre à ta dernière question je suis en 32bits, mais le 64 n'est pas très loin dans le planning... :-)

[Slyteck]

Me revoilà ! Et je viens apporter des précisions sur mon problème, puisque ce n'est pas exclusivement lié au fait de passer par un service.

J'ai un EXE (développé en Delphi) qui utilise la même dll. Et je viens de me rendre compte que là aussi, cela plante sur les FreeLibrary de cette dll.

Vous me direz, mais pourquoi tu ne l'as pas vu avant ? Tout simplement parce que les Freelibrary avaient été oublié !

Je pose donc la question (bien que j'ai vu un autre sujet là-dessus) : les FreeLibrary sont-ils si indispensables que ça ?
Car en débugant, j'ai constaté que toutes les procédures Destroy de ma dll s'exécute complètement...

[ShaiLeTroll]

Même si Windows libère à la fermeture d'un EXE tous les petits mais il vaut mieux être propre et faire ses FreeLibrary !

J'ai eu le même problème des FreeLibrary qui bloquait, certains parce qu'ils libéraient des DLL contenant des threads, hors le FreeLibrary était fait après la boucle RUN dans la section Finalization !
Une sorte de dead-lock qui rendait difficile l'arrêt des threads !
Pour ma part, j'ai donc anticipé l'appel des FreeLibrary d'ailleurs les DLL que j'utilisais, il était nécessaire d'appeler une méthode Clean et cela AVANT le FreeLibrary, comme j'avais une DLL intermédiaire qu'ai pensé pouvoir faire le Clean durant le FreeLibrary de ma DLL mais non, il fallait le faire AVANT !

J'ai évoqué cela dans EAccessViolation à la fermeture de l'application

[Slyteck]

Salut Shai,

Je n'ai pas de CleanUp() en Delphi et je ne vois pas trop ce qui s'en rapproche.

J'ai débuggé ma dll (développé en Delphi5) et il n'y a aucune exception jusqu'à la fin de mon DataModule.Destroy (mon DM étant mon point d'entrée)

Je sèche...

[ShaiLeTroll]

Je ne connais pas ta DLL ni les objets internes que tu utilises ni ta façon de les créer et libérer, le CleanUp reprend l'idée des bien connus Coinitialize et CoUninitialize du COM, ou GdiplusStartup\GdiplusShutdown de GDI+, idem pour DirectDraw ...
C'est une classique Microsoft, ce n'est pas un Hasard !

Tu pourrais ajouter ta méthode de nettoyage à appeler avant le FreeLibrary qui libérerait les Objets !

Partages-tu des objets entre DLL et EXE ? utilises-tu borlndMM.dll ?

[Slyteck]

Non, il n'y a pas d'objet partagé entre ma dll et mon exe.
Je charge la dll, j'execute la fonction que j'y ai exportée, et je libère la dll.

Cette dll, développé en Delphi5, sert à lancer une édition via Crystal (d'où mon parallèle dans un autre sujet concernant une migration de cette dll en Delphi 2010 ) avec saisie de paramètres dans une form.

Ce qui est étrange, c'est que cette dll se libérait très bien quand mon composant TDataBase utilisait SQLInks pour se connecter à ma base Informix. Dans un soucis de compatibilité avec mon exe migré, lui, en ADO, mon composant BDE, en attendant de le migrer lui aussi en ADO, utilise maintenant un driver ODBC fournit par OLEDB.
C'est avec ce changement que la libération plante... Bien que je ne constate aucun problème dans l'exécution de cette dll, qui édite très bien...
Voilà, je crois que j'ai tout dit là.

PS : Et oui, j'utilise borlndMM.dll

[Slyteck]

Mouarf !!

Je viens de tomber là-dessus...

C'est exactement mon problème... Mais la solution est très pro !

[ShaiLeTroll]

Un thread secondaire, pas de surprises !

Ah oui, j'aime beaucoup la résolution "Supprimez l'appel de FreeLibrary explicite pour la DLL à l'aide de ODBC32.dll."

Ben, voilà, si MS dit de faire un truc dégueux, pourquoi se gêner !

[Slyteck]

Il n'y a pas moyen de trouver ce thread et de le tuer moi-même ?
Mais là, je ne sais pas comment faire.

[ShaiLeTroll]

Pas évident, avec une fonction genre CreateToolhelp32Snapshot avec le TH32CS_SNAPTHREAD appelé AVANT et APRES le LoadLibrary
Tu ne liste que les thread de ton processs (voir th32OwnerProcessID)
Tu peux en déduire les nouveaux threads !
A tes risques et pire de faire un TerminateThread dessus

Voir si il existe un EnumThreads équivalent à EnumWindows