Opened 11 years ago
Last modified 5 years ago
#5228 closed defect
Loading a plugin on windows retains a library handle reference which causes memory problems — at Version 3
Reported by: | damiandixon | Owned by: | warmerdam |
---|---|---|---|
Priority: | low | Milestone: | closed_because_of_github_migration |
Component: | default | Version: | 1.10.0 |
Severity: | minor | Keywords: | |
Cc: |
Description (last modified by )
Loading a plugin on windows retains a library handle reference which causes memory retention problems (potential multiple initialization).
The function CPLGetSymbol on windows calls LoadLibrary. When LoadLibrary is called the DLL reference count is incremented.
When I call:
GDALDestroyDriverManager();
I would expect everything to be cleaned up and when I unload my DLL which is using GDAL I would expect the GDAL DLL to also unload. The GDAL DLL does not unload.
I have traced the issue down to the loading of plugins. If a plugin is successfully loaded the GDAL DLL remains in process memory.
I think that CPLGetSymbol should be split into two methods:
The first returns a void* ptr to a Library.
The second takes the ptr and a method name and returns a ptr to the method.
A new method should be introduced to free a library.
In GDALDriverManager::AutoLoadDrivers() a reference needs to be taken to the library loaded. A reference to the DLL/so also needs to be taken in OGRSFDriverRegistrar::AutoLoadDrivers().
In GDALDriverManager::~GDALDriverManager() and OGRCleanupAll() the reference to the libraries loaded need to be used to free the libraries.
The approach in CPLGetSymbol is likely to be an issue on other platforms where GDAL is used via a loaded DLL/so.
I'm going to look at doing a local fix but that's unlikely to be acceptable as a patch as I am currently only using GDAL on Windows.
Change History (3)
comment:1 by , 11 years ago
Description: | modified (diff) |
---|
comment:2 by , 11 years ago
Description: | modified (diff) |
---|
comment:3 by , 11 years ago
Description: | modified (diff) |
---|
Rather than initially using LoadLibrary it might be more sensible to use GetModuleHandle first then fall back to LoadLibrary.
This would ensure that the library's reference count is only incremented once on first load of the library.
This is I think only a stop gap as I still need away of unloading the shared libraries.
The ideal solution is the match the LoadLibrary calls to FreeLibrary calls. From experience this is more than likely going to affect non-windows platforms.