Even,
Thanks, but this was another thing. I fixed a bug in GMT where under
certain circumstances we were doing some overflowing access to the
contents of the 'tmp' variable returned by
GDALRasterIO(hBand, GF_Read, xOrigin, yOrigin, nXSize, nYSize,
tmp,
nBufXSize, nBufYSize,
GDALGetRasterDataType(hBand), 0, 0);
but this whole issue might not be all over yet.
Joaquim
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 <[email protected]> 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
>>> [email protected]
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> ----
>> http://schwehr.org
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
