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... From: Robbie Price Sent: Monday, 16 March 2015 2:57 p.m. To: 'gdal-dev@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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
