[gdal-dev] trouble with netCDF in C#?

[Etienne Tourigny]

Does this happen when you use gdal_translate to copy the netcdf file to
another format (say gtiff)?

I am not familiar with c# but there must be a way to compile gdal and you
application to get the exact line of code that causes the crash?

Etienne

On Mon, Mar 16, 2015 at 8:57 AM, Robbie Price <PriceR at landcareresearch.co.nz
> wrote:

>  I’m having trouble converting some netcdf (version 3) files to Kea files
> using the GDAL C# bindings.
>
>
>
> The problem is some form of memory leak caused by the netCDF code (from
> what I can establish through various tests).
>
>
>
> There are two issues:
>
> 1)       A memory leak in this call (which I noticed, but can work around
> as I am only dealing with a small number of subdatasets)
>
> a.  dsNetCDF = OSGeo.GDAL.Gdal.Open(strNetCDF_DSN, OSGeo.GDAL.Access
> .GA_ReadOnly);
>
> 2)      A memory issue/leak pointer assignment causing a crash that I
> cannot trace the error reports as:
>
>
>
> Managed Debugging Assistant 'FatalExecutionEngineError' has detected a
> problem in
> 'O:\Projects\KEA_ReadWrite\bin\x64\Debug\KEA_ReadWrite.vshost.exe'.
>
> Additional Information: The runtime has encountered a fatal error. The
> address of the error was at 0xebc85654, on thread 0x16ec. The error code is
> 0xc0000005. This error may be a bug in the CLR or in the unsafe or
> non-verifiable portions of user code. Common sources of this bug include
> user marshaling errors for COM-interop or PInvoke, which may corrupt the
> stack.
>
>
>
> The error is consistent in nature but happens inconsistently in the code
> (between 1800 and 4000 bands) – here from another run:
>
> Managed Debugging Assistant 'FatalExecutionEngineError' has detected a
> problem in
> 'O:\Projects\KEA_ReadWrite\bin\x64\Debug\KEA_ReadWrite.vshost.exe'.
>
> Additional Information: The runtime has encountered a fatal error. The
> address of the error was at 0xebc85654, on thread 0x199c. The error code is
> 0xc0000005. This error may be a bug in the CLR or in the unsafe or
> non-verifiable portions of user code. Common sources of this bug include
> user marshaling errors for COM-interop or PInvoke, which may corrupt the
> stack.
>
>
>
> The error *MAY* be occurring more often only on lines handling string
> functions (?)
>
>
>
> Version Details
>
>
>
> Using MSVS 2010 (C#) and the following:
>
>
>
>
> http://www.gisinternals.com/query.html?content=filelist&file=release-1600-x64-gdal-mapserver.zip
>
>
>
> *gdal-200-1600-x64-core.msi*
> <http://download2.gisinternals.com/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver/gdal-200-1600-x64-core.msi>
>
> 3/15/2015 4:13 AM
>
> 21556 kB
>
> Generic installer for the GDAL core components
>
>
>
>
>
> Basic scenario is converting from one file type to another but taking the
> meta info from the NetCDF and using as band name info in the Kea file.
> Input files have between 365 and 8000 bands but not large spatially
> (260*243).
>
> ------------------------------
>
> Please consider the environment before printing this email
> Warning: This electronic message together with any attachments is
> confidential. If you receive it in error: (i) you must not read, use,
> disclose, copy or retain it; (ii) please contact the sender immediately by
> reply email and then delete the emails.
> The views expressed in this email may not be those of Landcare Research
> New Zealand Limited. http://www.landcareresearch.co.nz
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150330/1acd3afd/attachment-0001.html>