search

MaxRev-Dev / gdal.netcore

GDAL 3.x C#/F# bindings for .NET apps
MIT License
161 stars 36 forks source link

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

Closed edwiles closed 2 weeks ago

edwiles commented 3 months ago

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.

MaxRev-Dev commented 3 months ago

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

edwiles commented 3 months ago

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.

MaxRev-Dev commented 3 weeks ago

@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.

edwiles commented 2 weeks ago

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.