dll's and memory
Author
Hi guys,
Ive got a quick question.
I am dynamically loading a dll into my program using LoadLibraryEx.
Is it neecssary to release the dll with FreeLibrary if I want the dll attached throughout the entire time my app is running? Would it cause a memory leak not too or would the dll be detached automatically when my app closes?
-CProgrammer
When a process shuts down everything loaded into it's address space is unmapped, including dynamically loaded dlls. However, a dll might in turn create and load system resources that need to be explicitly unloaded. Calling FreeLibrary insures that happens if it needs too. If that needs to happen and doesn't, it could lead to unreferenced system resources, kind of like a dangling pointer. For best results (and good practice) every call to LoadLibrary (et al.) should be matched with a call to FreeLibrary (et al).
Why not checking the FreeLibrary function on MSDN ?
I believe that you have to call FreeLibrary explicitly in your program, otherwise, you waste some win32 resources. This article seems to provide details : It could be interesting to check whether or not the code in DLL_PROCESS_DETACH is executed in the DLL when you exit your main program, without calling FreeLibrary...
Cheers
StratBoy61
I believe that you have to call FreeLibrary explicitly in your program, otherwise, you waste some win32 resources. This article seems to provide details : It could be interesting to check whether or not the code in DLL_PROCESS_DETACH is executed in the DLL when you exit your main program, without calling FreeLibrary...
Cheers
StratBoy61
Author
Thanks guys. That makes a lot of sense.
I just had a bit of a weird design issue where I am designing a dll plugin which loads another dll. Sadly the program the plugin is for never actually calls any initialization routines except offcourse DllMain. Since LoadLibrary and Dllmain don't get along I had to insert a library loading function on every possible first function call. Not being able to know in this particular design when the last call is ughh. So Its either reference counting or just not using FreeLibrary. I guess Ill do the reference counting.
Thanks again.
I just had a bit of a weird design issue where I am designing a dll plugin which loads another dll. Sadly the program the plugin is for never actually calls any initialization routines except offcourse DllMain. Since LoadLibrary and Dllmain don't get along I had to insert a library loading function on every possible first function call. Not being able to know in this particular design when the last call is ughh. So Its either reference counting or just not using FreeLibrary. I guess Ill do the reference counting.
Thanks again.
Quote:Original post by CProgrammer
Since LoadLibrary and Dllmain don't get along ...
What???
Quote:Original post by LessBreadQuote:Original post by CProgrammer
Since LoadLibrary and Dllmain don't get along ...
What???
Quote:MSDN: DllMain
Warning There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. Alternatively, the initialization routine can create a file with an ACL that restricts access, and each routine in the DLL would call the initialization routine if the file does not exist.
...
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.
Wow ! I do not get it : If you cannot load a dll from the DllMain, how can dlls load other dlls in cascade ? For instance, you create your own dll(1), you link it with an import .LIB that will create dependencies to another dll(2), how does it work ? Where are the calls to LoadLibrary to dll(2) in dll(1) ?
In your case, I was thinking of maybe using a smart-pointer singleton in your dll(1), that would load dll(2). But I think it would more or less still be called from DllMain (I do not know *when* exactly global variables are instanciated, and thus executed when it is a class constructor)...
In your case, I was thinking of maybe using a smart-pointer singleton in your dll(1), that would load dll(2). But I think it would more or less still be called from DllMain (I do not know *when* exactly global variables are instanciated, and thus executed when it is a class constructor)...
Quote:Original post by AgonyQuote:Original post by LessBreadQuote:Original post by CProgrammer
Since LoadLibrary and Dllmain don't get along ...
What???Quote:MSDN: DllMain
...
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.
I see. I had forgot about that. I was thinking that the statement was odd because a call to LoadLibrary produces a call to entry point function of the dll, which suggests that they do get along. It would seem that DllMain doesn't get along well with LoadLibrary more than the other way around.
Quote:Original post by StratBoy61
Wow ! I do not get it : If you cannot load a dll from the DllMain, how can dlls load other dlls in cascade ? For instance, you create your own dll(1), you link it with an import .LIB that will create dependencies to another dll(2), how does it work ? Where are the calls to LoadLibrary to dll(2) in dll(1) ?
Statically linked dlls are loaded when the dll that links to them is loaded. Here are a couple of articles on how LoadLibrary does it's thing.
A tour of part of the Windows NT® loader code
What Goes On Inside Windows 2000: Solving the Mysteries of the Loader
The trouble arises when a dll dynamically links with other dlls. Per Agony's post, in that situation you would need to craft a separate initialization function in the dll that would in turn load in the other dlls. Calling LoadLibrary from within DllMain could produce a nasty recursive situation.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
