Memory access violation

[rouen-sk]

When I am debugging my tile server based on NET-Mapnik, it happens quite often that debugger stop on Render() with the following exception. However, after continuing, the tile in fact is generated OK.

An unhandled exception of type 'System.AccessViolationException' occurred in NETMapnik.dll

Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

   at mapnik.feature_style_processor<mapnik::agg_renderer<mapnik::image<mapnik::rgba8_t>,mapnik::label_collision_detector4> >.apply

(feature_style_processor<mapnik::agg_renderer<mapnik::image<mapnik::rgba8_t>\,mapnik::label_collision_detector4> >* , Double )
   at NETMapnik.agg_renderer_visitor.()(agg_renderer_visitor* , image<mapnik::rgba8_t>* pixmap)
   at 

mapnik.util.detail.dispatcher<NETMapnik::agg_renderer_visitor,mapnik::image_any,void,mapnik::image<mapnik::rgba8_t>,mapnik::image<mapnik::gray8_t>,mapnik::image<mapnik::gray8s_t>,mapnik::imag

e<mapnik::gray16_t>,mapnik::image<mapnik::gray16s_t>,mapnik::image<mapnik::gray32_t>,mapnik::image<mapnik::gray32s_t>,mapnik::image<mapnik::gray32f_t>,mapnik::image<mapnik::gray64_t>,mapnik::

image<mapnik::gray64s_t>,mapnik::image<mapnik::gray64f_t> >.apply(image_any* v, agg_renderer_visitor f)
   at 

mapnik.util.detail.dispatcher<NETMapnik::agg_renderer_visitor,mapnik::image_any,void,mapnik::image<mapnik::null_t>,mapnik::image<mapnik::rgba8_t>,mapnik::image<mapnik::gray8_t>,mapnik::image<

mapnik::gray8s_t>,mapnik::image<mapnik::gray16_t>,mapnik::image<mapnik::gray16s_t>,mapnik::image<mapnik::gray32_t>,mapnik::image<mapnik::gray32s_t>,mapnik::image<mapnik::gray32f_t>,mapnik::im

age<mapnik::gray64_t>,mapnik::image<mapnik::gray64s_t>,mapnik::image<mapnik::gray64f_t> >.apply(image_any* v, agg_renderer_visitor f)
   at 

mapnik.util.variant<mapnik::image<mapnik::null_t>,mapnik::image<mapnik::rgba8_t>,mapnik::image<mapnik::gray8_t>,mapnik::image<mapnik::gray8s_t>,mapnik::image<mapnik::gray16_t>,mapnik::image<m

apnik::gray16s_t>,mapnik::image<mapnik::gray32_t>,mapnik::image<mapnik::gray32s_t>,mapnik::image<mapnik::gray32f_t>,mapnik::image<mapnik::gray64_t>,mapnik::image<mapnik::gray64s_t>,mapnik::im

age<mapnik::gray64f_t> >.visit<struct NETMapnik::agg_renderer_visitor,struct mapnik::image_any>(image_any* v, agg_renderer_visitor f)
   at mapnik.util.?A0x2794f542.apply_visitor<struct mapnik::image_any,struct NETMapnik::agg_renderer_visitor>(agg_renderer_visitor f, image_any* v)
   at NETMapnik.Map.Render(Image image, IDictionary`2 options)
   at NETMapnik.Map.Render(Image image)
   at (my code)
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
   at System.Threading.Tasks.Task.ExecuteEntry(Boolean bPreventDoubleExecution)
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

[wilhelmberg]

Might be an upstream issue, that should be fixed by now.

mapnik/node-mapnik#437
mapnik/node-mapnik#406

[rouen-sk]

@jbrwn Is there any chance you will release new version any time soon? Current is based on the year-old mapnik-win-sdk-14.0-x64-v3.0.0-rc1-1158-g73dbec3.7z. Many bugs were fixed by now for sure.
I tried myself - downloaded mapnik-win-sdk-v3.0.11-x64-14.0.7z and replaced the \lib\x64\mapnik-sdk directory and tried to build, but that was too optimistic, I guess - got 350 errors, and since I am not C++ programmer, I have no idea how to fix most of them...

[jbrwn]

@rouen-sk unfortunately, I have not been working on a new release. I just haven't had the time or motivation. That being said, if you want to keep plugging away at I would more than willing to help out when I can and provide support.

I tried myself - downloaded mapnik-win-sdk-v3.0.11-x64-14.0.7z and replaced the \lib\x64\mapnik-sdk directory and tried to build, but that was too optimistic, I guess - got 350 errors, and since I am not C++ programmer, I have no idea how to fix most of them...

c++ can be cold bitch sometimes. The new version of mapnik sdk likely has a handful (or more) of api changes that are causing things to break. Let me know if you want to keep hacking at it and I can get a branch going, a CI job on appveyor, and/or anything else you need.

[Charmatzis]

I also would like to help with developing C# bindings of mapnik and maybe use the new .NET Core.
Can we create a team, submit some milestones and figure out what can we do?

PS. I also am not a C/C++ developer, but maybe I can find a friend to help us.

[jbrwn]

Can we create a team, submit some milestones and figure out what can we do?

Yes, most definitely. If the interest is there and folks are willing to contribute then i am game to get the ball rolling.

maybe use the new .NET Core.

I agree that this is the best path forward. Unfortunately, this project is currently written in c++/cli which will probably never be compatible with .NET Core - dotnet/coreclr#659. To target .NET Core we would need to re-write everything using p/invoke references to the native mapnik SDK. Even then, there still may be challenges as referencing native libraries from the .NET Core is still a work in progress - aspnet/dnx#402. To be honest, this is biggest reason why i lost motivation with this project last year. I was pretty bummed when i realized what it would take to make the project cross-platform and .NET Core compatible. That being said, .NET Core has matured quite a bit in the last year, and i feel more optimistic about the re-write after taking another look just now.

Ok, Here are the potential options/milestones i see for future development:

1. Update project to use latest mapnik sdk. This will continue to target .NET Framework 4.6 and windows only.
2. Re-write the project to target .NET Core. This will obviously be a lot of work but there are some silver linings - p/invoke does not actually involve writing any c++ so it will probably be easier for c# developers to contribute.

I am not super excited about option 1 but i do realize it is the probably the quickest way to ship a new release. I would support that kind of effort if someones else takes the lead but i am not very likely to put in a lot of my own dev time. Option 2 is a lot more appealing to me. I could see myself putting in a good amount my own time towards a re-write. What do you guys think?

[Charmatzis]

Hi, @jbrwn . I also don't have much free dev time to spend, but the NET-Mapnik is something that I will use in future projects. So I am willing to help, as much as I can and even more.

Finally, I have no experience p/invoke references for C#, but I am willing to learning all about that.
I believe we have to write something like that Kestrel based on Libuv.
If we gather a team @jbrwn can you guide us and organize to start working?

[rouen-sk]

Hi guys, nice to see it is not entirely dead here. I am in fact part of the company and we are evaluating NET-Mapnik as a part of our product. So I got a c++ capable colleague working on "option 1". I will let you know as soon as possible.
I also agree that rewrite to pure managed code with Core compatibility in mind is good idea and we will contribute for sure.