[gdal-dev] Trying to debug a GDAL crash in "GDALClose(hDataset); "

Even Rouault even.rouault at spatialys.com
Sun Nov 15 04:33:59 PST 2015


Le dimanche 15 novembre 2015 01:41:12, Joaquim Luis a écrit :
> Ok I went ahead I tried it myself. It doesn't crash on OSX

Perhaps it is an issue similar to
https://trac.osgeo.org/gdal/ticket/5829 ?

Several workarounds :
- make sure all datasets are closed with GDALClose() before process 
termination (cleanest solution)
- set the env variable GDAL_DESTROY to NO to prevent the termination routine 
of GDAL from run and attempting to close any remaining opened dataset

> 
> > My bad, I don't know how to produce a stack trace from within the VS
> > debugger. I have it all visually but find no option to save it as a file.
> > 
> > I added a breakpoint at  cpl_atomic_ops.cpp#L56 but it didn't stop there
> > after the call to   GDALClose(hDataset);Actually when stepping in  it
> > jumps directly from GDALClose() into CPLAtomicCompareAndExchange() but
> > once there (due to crash) I can step back >to other functions.
> > Sorry if it's not clear.
> > 
> > Do you have a GMT build with GDAL svn? Could you please try if this
> > crashes for you
> > 
> > grdmath -Rd -I1 X = lixo.tiff:GTiff
> > grdinfo -R0/20/30/50 lixo.tiff
> > 
> >> nLockCount should be set by
> >> 
> >> https://trac.osgeo.org/gdal/browser/trunk/gdal/gcore/gdal_priv.h#L598
> >> 
> >> https://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_atomic_ops.cpp#L
> >> 56
> >> 
> >> which uses InterlockedCompareExchange to change it.
> >> 
> >> Can you give the whole stack trace?
> >> 
> >> On Fri, Nov 13, 2015 at 6:47 PM, Joaquim Luis <jluis at ualg.pt> wrote:
> >>> Hi,
> >>> 
> >>> I'm having strange crashes in GDAL (SVN) when called via GMT. The
> >>> crashes occur at a call to
> >>> 
> >>> GDALClose(hDataset);
> >>> 
> >>> Now, this is only occurs when I try to read a sub-region of a grid but
> >>> those are GMT details.
> >>> It doesn't happen to colleagues on OSX but they are using gdal 1.11.
> >>> Can't say that's the reason but this used to work for me as well on
> >>> Windows >>>(I should know because I wrote that code).
> >>> 
> >>> I built a GDAL debug and can see that the crash happens in
> >>> cpl_atomic_ops.cpp
> >>> 
> >>> int CPLAtomicCompareAndExchange(volatile int* ptr, int oldval, int
> >>> newval)
> >>> {
> >>> 
> >>>  return (LONG)InterlockedCompareExchange((volatile LONG*)(ptr),
> >>> 
> >>> (LONG)newval, (LONG)oldval) == (LONG)oldval;
> >>> }
> >>> 
> >>> because the 'ptr' is invalid. That function is called by
> >>> gdalrasterblock.cpp
> >>> 
> >>> GDALRasterBlock::DropLockForRemovalFromStorage()
> >>> 
> >>>        if( CPLAtomicCompareAndExchange(&nLockCount, 0, -1) )
> >>> 
> >>> and the debugger tells me that
> >>> 
> >>>        nLockCount      <Unable to read memory>
> >>> 
> >>> and here I'm lost. Where is nLockCount supposed to be set?
> >>> 
> >>> Thanks
> >>> 
> >>> Joaquim
> >>> _______________________________________________
> >>> gdal-dev mailing list
> >>> gdal-dev at lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >> 
> >> ----
> >> http://schwehr.org

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list