Memory deallocation issue using MrSID dll as a plug-in

[christian.ratliff@…]

We use GDALOpen to open the MrSID file, seems to be no problem as we can access
the raster band data and extract good imagery.  GDALClose causes a problem however.

When we go to close using GDALClose we get the UnHandled Exception. Tracing
through GDAL in GDALClose we find that the pointer to the Mr.Sid driver looks
valid.  Next when the pointer to the driver instance is deleted an unhandled
exception occurrs.  A bounds checker report states that the memory is of the
wrong type (free instead of delete) - but we tried to use free and although it
didn't throw an exception, a LARGE leak resulted.  We believe there is a
compatibility problem with the MrSid driver implementation when used as a plug-in.

for example:

this is used to open the dataset, with fileName being a *.sid file...

m_pDS = (GDALDataset*)GDALOpen( fileName.c_str(), GA_ReadOnly );

....
data access
....

and when cleanup occurrs:

GDALClose((GDALDatasetH)m_pDS)

this causes an excpetion...  we should point out that in our configuration we
have the MrSid lib from LizzardTech as a standalone dll - and so we are using it
as a plug-in.  The initialization of the plug-in is as follows:



CPLSetConfigOption("GDAL_DATA", strDataPath.c_str());
CPLSetConfigOption("GDAL_DRIVER_PATH", strDriverPath.c_str());
CPLSetConfigOption("GDAL_PAM_ENABLED", "YES");

#if defined(_DEBUG)
CPLSetConfigOption("PROJSO", "PROJ4D.DLL");
#else
CPLSetConfigOption("PROJSO", "PROJ4.DLL");
#endif

finally, to be specific, the excpetion occurrs in file: gdaldataset.cpp
delete poDS;

[warmerdam]

Christian, 

My first instinct is that this would relate to having a different heap for
the plugin and the GDAL DLL.  Are both compiled with /MD? (I imagine I'm 
repeating the cop-out I've used before when we chatted about this). 

Also, what version of the mrsid sdk are you using.  I've just upgraded to 
DSDK 6.0.7.1407 and it might help if we had similar environments before digging
into this too far.  I'm also using Visual Studio 7.1 (aka 2003). 

[warmerdam]

Frank I think I've found the problem...  The following link to a known
memory issue is referenced in LTI's install issues.

http://support.microsoft.com/default.aspx?scid=kb;en-us;122675

The problem described is very possibly the one we are dealing with.
Essentially for objects that are allocated inside a dll, exported and
deleted outside the new/delete helper functions have different
structures
depending on where they are used... heap vs stack etc.

See Geo_DSDK-6.0.7.1407\DOC\issues.txt -> the link above gives
suggestions
for working around the problem.

Todd Wetzel

[warmerdam]

I rebuilt GDAL with /MDd (and the debug lizardtech DLL) and then was
able to reproduce the problem in question.   The lizardtech docs, and
the knowledgebase article suggest a technique involving wrapping the 
in-question objects with a template class.  I have implemented this, and
it seemed to correct the problem for all classes except LTINavigation.  

So, I have changed the code to not delete the LTINavigation on WIN32 systems,
and to use templates for all the other dynamically allocated objects from
the SDK.  This seems to give correct operation when using /MDd. 

This change has been committed in CVS.  I would appreciate your testing it
at your end, and closing if it seems to fix the problem.

[hobu]

Christian,

Can we close this one?

Howard

[hobu]

Appears to be fixed with a newer release of the MrSID stuff.  Closing...