[Delphi] Probleem met unloaden DLL

[Knutselsmurf]

Ik ben bezig met een applicatie in Delphi en daarbij wordt gewerkt met plugins in de vorm van DLL's. Hierbij wordt van iedere plugin alle gegevens opgeslagen in een record. Dit gaat allemaal goed. Echter bij het afsluiten van het programma moeten alle DLL's weer verwijderd worden. Dit gebeurt met de API-functie FreeLibrary. Dat gaat niet goed. Om de een of andere reden blijft hij oneindig lag in die functie hangen. Heeft er iemand enig idee wat er hier verkeerd gaat?

[Tom-my]

Waar gaat het fout met debuggen, want ik neem aan dat je dat gedaan hebt? zo kan je toch wel terug vinden waar het zakie blijft hangen.

[Knutselsmurf]

FanToom schreef op 08 augustus 2002 @ 13:35:
Waar gaat het fout met debuggen, want ik neem aan dat je dat gedaan hebt? zo kan je toch wel terug vinden waar het zakie blijft hangen.

Het gaat helemaal goed, totdat de FreeLibrary wordt aangeroepen. En die kan ik helaas niet debuggen in Delphi

[Verwijderd]

Kun je een stukje code laten zien.

Wat is dat voor soort plugin. Is het een echte DLL of een BPL -> deze moeten je laden met LoadPackage (of zo iets).

Denk ook es aan het volgende:

* Doet de plugin nog wat tijdens het laden
* welke andere dll gebruikt ie

[Knutselsmurf]

Verwijderd schreef op 08 augustus 2002 @ 13:38:
Kun je een stukje code laten zien.

Wat is dat voor soort plugin. Is het een echte DLL of een BPL -> deze moeten je laden met LoadPackage (of zo iets).

Denk ook es aan het volgende:

* Doet de plugin nog wat tijdens het laden
* welke andere dll gebruikt ie

Het is een DLL en geen BPL.

De plugin werkt zonder problemen. Alles gaat goed, totdat hij dus vrijgegeven moet worden. Ook de handle is correct op het moment van het aanroepen van FreeLibrary. Het rare is dus dat ik geen foutmelding krijg ofzo, maar er gebeurt helemaal niets.

[Delphi32]

Heb je de source van de DLLs? Hebben die DLLs een DllEntryPoint? Zo ja, moet je daar maar eens gaan kijken. De DLLs worden toch hopelijk ook geladen met LoadLibrary? Voor zover ik hiervandaan kan beoordelen, kan alleen de DllEntryPoint roet in het eten gooien. Of je moet zeer brakke code in de finalization section van een van de DLL units hebben zitten.

[Tomatoman]

Dit klinkt alsof de DLL nog in gebruik is op het moment dat je hem wilt unloaden. Dat kan bijvoorbeeld gebeuren als je wel RegisterComponents na het laden aanroept, maar niet UnregisterComponents vóór het unloaden.

[Knutselsmurf]

Delphi32 schreef op 08 augustus 2002 @ 23:51:
Heb je de source van de DLLs? Hebben die DLLs een DllEntryPoint? Zo ja, moet je daar maar eens gaan kijken. De DLLs worden toch hopelijk ook geladen met LoadLibrary? Voor zover ik hiervandaan kan beoordelen, kan alleen de DllEntryPoint roet in het eten gooien. Of je moet zeer brakke code in de finalization section van een van de DLL units hebben zitten.

Uiteraard heb ik ook de code van die DLL's, want die zijn ook zelf geschreven. Deze worden netjes geladen met LoadLibrary. De DLL heeft geen finalization, dus de kans dat daar brakke code in zit is vrij klein

[Knutselsmurf]

tomatoman schreef op 09 augustus 2002 @ 00:16:
Dit klinkt alsof de DLL nog in gebruik is op het moment dat je hem wilt unloaden. Dat kan bijvoorbeeld gebeuren als je wel RegisterComponents na het laden aanroept, maar niet UnregisterComponents vóór het unloaden.

De DLL beval 1 form, die wordt gefreed voor het unloaden. Verder wordt er niets gedaan met Registercomponents.

[Creepy]

Debug je DLL eens dan.. kan je echt zien of het daar wel of niet in zit.
Ennuh. je kan in Delphi niet debuggen??? Welke versie gebruik je dan? Ik dacht dat je zelfs kon debuggen in de Open versie van Delphi.

[Knutselsmurf]

Creepy schreef op 09 augustus 2002 @ 08:53:
Debug je DLL eens dan.. kan je echt zien of het daar wel of niet in zit.
Ennuh. je kan in Delphi niet debuggen??? Welke versie gebruik je dan? Ik dacht dat je zelfs kon debuggen in de Open versie van Delphi.

De DLL kan ik wel debuggen, daar gebeurt niets raars in. Echter de FreeLibrary API-functie, die daarna wordt aangeroepen blijft oneindig lang werken. En die functie zelf kan ik dus niet debuggen/tracen, omdat dat een windows-functie is.....

[LordLarry]

Luisters Knutselsmurf. Als je niet meer verteld en geen code laat zien komen we er nooit uit. Dat jij vind dat het allemaal goed en slecht gaat is leuk, maar dan kan niemand wat mee.

[Creepy]

Ik denk toch echt dat er een fout zit in je APP of je DLL, dan in de Windows API FreeLibrary hoor. Anders had 99% van de windows app's niet gedraait.

Dus post de init/deinit code van je DLL eens, en de load/unload code in je app (en de bijbehorende struct). En zoals al opgemerkt was, doe je iets met DLLEntrypoint? Die moet natuurlijk ook weer netjes worden teruggezet.

[Elissen]

Stukje uit de Platform SDK, opmerkingen over FreeLibary:

Before unmapping a library module, the system enables the DLL to detach from the process by calling the DLL's DllMain function, if it has one, with the DLL_PROCESS_DETACH value. Doing so gives the DLL an opportunity to clean up resources allocated on behalf of the current process. After the entry-point function returns, the library module is removed from the address space of the current process.

Wellicht heb je code in een finalization sectie staan?

[Knutselsmurf]

Intussen is het probleem al iets verder gespecificeerd. Code in een finalization-sectie is geen enkel probleem, die wordt netjes uitgevoerd.(Gecontroleerd mbv tracen). Echter bij de finalization van Gifimage(niet zelf geschreven), wordt een Thread gefreed en DAAR blijft hij op hangen. Op de een of andere manier wordt die thread dus nooit vrijgegeven. Dit probleem treedt niet op als Gifimage direct in een applicatie gebruikt wordt.
LordLarry: Ik kan hier wel de code laten zien waarin de Loadlibrary staat en de FreeLibrary, maar daar is niets uit te halen. Die is namelijk exact gelijk aan alle voorbeelden zoals ze op internet staan.

-----

Intussen is het probleem opgelost. Het bleek, dat er in Gifimage een dummy Thread werd aangemaakt, om een bug in Delphi 3+ te omzeilen. In Delphi 6 bleek dat dus uiteindelijk niet meer nodig. Andere applicaties in Delphi 6 hadden geen probleem, maar in combinatie met een DLL ging het dus niet goed. De oplossing was dus het installeren van een onofficiele, voor Delphi 6 geoptimaliseerde, Gifimage.

[LordLarry]

Goed dat je het hebt gevonden.

LordLarry: Ik kan hier wel de code laten zien waarin de Loadlibrary staat en de FreeLibrary, maar daar is niets uit te halen. Die is namelijk exact gelijk aan alle voorbeelden zoals ze op internet staan.

Die code niet alleen, maar ook bijvoorbeeld code in de finalization en/of destrucors. Het laten zien van code werkt stukke sneller en beter dan het melden of iets wel of niet werkt. De programmeur ziet zijn eigen code weer eens en andere mensen kunnen ook zien of er rare dingen inzitten. Omdat ik ook een programmeur ben weet ik dat je soms 'blind' wordt voor code en je, hoe makkelijk de fout ook is, het gewoon niet ziet. Het doornemen en uitleggen van de code aan andere mensen forceerd dat je er nog eens goed naar gaat kijken en lost vaak veel van de problemen op.

[Knutselsmurf]

LordLarry schreef op 09 augustus 2002 @ 13:22:
Goed dat je het hebt gevonden.

[...]

Die code niet alleen, maar ook bijvoorbeeld code in de finalization en/of destrucors. Het laten zien van code werkt stukke sneller en beter dan het melden of iets wel of niet werkt. De programmeur ziet zijn eigen code weer eens en andere mensen kunnen ook zien of er rare dingen inzitten. Omdat ik ook een programmeur ben weet ik dat je soms 'blind' wordt voor code en je, hoe makkelijk de fout ook is, het gewoon niet ziet. Het doornemen en uitleggen van de code aan andere mensen forceerd dat je er nog eens goed naar gaat kijken en lost vaak veel van de problemen op.

Hier heb je helemaal gelijk in, maar om nu direct 25 finalization-secties, waarin alleen maar free's staan, hier neer te zetten is ook een beetje overdreven. Bovendien heeft die code wel gewerkt. In eerste instantie was het namelijk een losse applicatie, die nu wordt om gezet naar een plugin. De algemene DLL-code was getest, net als de oorspronkelijke applicatie. Na samenvoegen ging het dus fout. Maar dat konden jullie natuurlijk niet weten Maar goed, de fout zat dus uiteindelijk niet in de eigen code, maar in de code van een component dat gebruikt wordt.