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 2
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 problems.
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 (2)
comment:1 by , 11 years ago
Description: | modified (diff) |
---|
comment:2 by , 11 years ago
Description: | modified (diff) |
---|