[gdal-dev] FW: trouble with netCDF in C#? PLEASE REMOVE ISSUE

Even Rouault even.rouault at spatialys.com
Mon Mar 16 21:52:24 PDT 2015


Selon Robbie Price <PriceR at landcareresearch.co.nz>:

> Hi,
>
> After much angst and wringing of hands I have resolved my problem - by
> looking in a totally different bit of my code to the area I though the error
> was occurring.
>
> The best way to track these issues turned out to be using GC.Collect(0) "A
> Lot".  As soon as one stuffs up the GC will know about it.  Brilliant!!!!!!
> (Just remember to comment them out when it is working)
>
> Lesson 1:
> I think my C# dynamic array definition and expecting the GDAL unmanaged code
> to automagically resize the array may be just a little optimistic.  I could
> not find a definitive statement on the size the array had to be so I got lazy
> and then forgot about it (this works inside Net just hunky dory).  I will
> have to find out the correct array size [maximum possible] and set it first:
>
> double[] adblGeoTransform = new double[0];
> dsNetCDF.GetGeoTransform(adblGeoTransform);
> agcpNetCDF = dsNetCDF.GetGCPs();
>
> whoops...
>

I'm not familiar with the C# bindings, but it is very likely t hatyou need to
set the array to 6 doubles, as it is its size in C/C++. See
http://gdal.org/gdal_tutorial.html

>
> From: Robbie Price
> Sent: Monday, 16 March 2015 2:57 p.m.
> To: 'gdal-dev at lists.osgeo.org'
> Subject: trouble with netCDF in C#?
>
> 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
>


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


More information about the gdal-dev mailing list