gdal.netcore icon indicating copy to clipboard operation
gdal.netcore copied to clipboard

[BUG] Access violation exception when running GdalBase.ConfigureAll()

Open edwiles opened this issue 1 year ago • 2 comments

Describe the bug

Since MaxRev.Gdal.Core 3.9.0.218 with MaxRev.Gdal.WindowsRuntime.Minimal 3.9.0.218, we are getting this error when running GdalBase.ConfigureAll() in an Azure app service:

Application: w3wp.exe
CoreCLR Version: 8.0.724.31311
.NET Version: 8.0.7
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Stack:
   at OSGeo.OSR.OsrPINVOKE.SetPROJSearchPaths(IntPtr[])
   at OSGeo.OSR.OsrPINVOKE.SetPROJSearchPaths(IntPtr[])
   at OSGeo.OSR.Osr.SetPROJSearchPaths(System.String[])
   at MaxRev.Gdal.Core.Proj.Configure(System.String[])
   at MaxRev.Gdal.Core.GdalBase.ConfigureAll()
   at (etc.)

This is an unrecoverable error - the application is immediately killed and automatically restarts.

This does not occur with MaxRev.Gdal.Core 3.8.3.286 and MaxRev.Gdal.WindowsRuntime.Minimal 3.8.3.259.

It also does not occur when running locally (Windows 11), either in Debug or Release mode (x64). It only occurs in our Azure app service, which is set to Windows 64-bit.

edwiles avatar Aug 13 '24 12:08 edwiles

Can you run restore these packages locally? This build should fix the issue of missing dependencies for Azure VM.

https://github.com/MaxRev-Dev/gdal.netcore/actions/runs/10375191648/artifacts/1808132653

MaxRev-Dev avatar Aug 13 '24 19:08 MaxRev-Dev

Thanks for looking at this so quickly, Max, and I see that this package has fixed the other reported issue with the Azure VM. Unfortunately in my case, I downloaded package 3.9.1.247 from NuGet as I noticed you'd uploaded it earlier today, and the problem remains as described. Note that I am using Azure App Service i.e. it is not any specific VM.

I have not tried the zipped package 3.9.1.246 you mention as I'd need to add the files explicitly to our build system in order to deploy it, but I can do that if it would help diagnose? Thanks a lot.

edwiles avatar Aug 14 '24 15:08 edwiles

@edwiles I'm not able to repro this with a free tier app as it's limited to 32-bits.

The difference between runtime 3.8.3.259 and 3.9.1.247 is that the redundant libraries packaged from the GisInternals SDK have been removed. The dependencies are checked with LDD and then getting packaged.

As it works in Windows, but fails for Azure App service, I suppose, it could be something with app build and it's configuration.

Please, ensure you have the platform set to x64 and not AnyCPU.

MaxRev-Dev avatar Nov 02 '24 04:11 MaxRev-Dev

Thanks, @MaxRev-Dev. Good news - I've just redeployed our app with 3.9.1.247, and it is now working. I didn't change anything else, so maybe our redeployment didn't clean up the files properly last time.

I've now closed this issue.

edwiles avatar Nov 04 '24 13:11 edwiles