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 damiandixon)

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 damiandixon, 11 years ago

Description: modified (diff)

comment:2 by damiandixon, 11 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.