springmeyer
Thread hanging in apply()
I apologie in advance if I'm posting my issue in the wrong place. I have done in the last year my own mapnik-jni (much simpler and "customized" than your) but I'm facing a pretty hard problem that maybe you already found and solved. My dataset is composed on many vector tiles so to draw then in multithread I allocate a set of mapnik::Map and I use them to draw the raster tile. The Threads are Java thread calling a jni function that make all the necessary settings and than call mapnik::agg_renderermapnik::image_32 ->apply() and return a bitmap. Now the issue is that apply() is "hanging" (not crashing) for all the threads (after sometimes) except 1. So after sometimes I always have only 1 thread really drawing, so it seems typical Multithread issue, but mapnik is compiled in MULTITHREAD, sqlite3 is compiled in MULTITHREAD, ... Debugging C++ code in Eclipse is nearly impossible so I'm stuck. Do you have any suggestion ? Many thanks for your support.
@cbo1964 can you share what Mapnik version and operating system you are seeing this on? Next step would be to profile the running process to see where it is hung. Check out https://github.com/springmeyer/profiling-guide for linux and osx. if you are on windows then I will recruit @BergWerkGIS to help add docs to the guide for windows.
Hi, I don't work on this anymore, but I think the next thing I would do would be to get a java and native stack dump.
If on Linux, do a "kill -QUIT $javapid" and a trace of all threads will be printed to the console. I believe there is a way to do this on windows but it is going back over ten years for me and I can't remember.
If that shows your java threads blocking in the native method, you'll need a native trace too. On Linux, attach gdb to your process (see man page for arguments) and run "thread apply all bt". Gdb will print full stack traces of each thread. If on windows, I think just attach visual studio or equivalent and look at the stack trace pane...
This will probably give the necessary clues. On Jul 15, 2015 8:10 AM, "Claudio" [email protected] wrote:
I apologie in advance if I'm posting my issue in the wrong place. I have done in the last year my own mapnik-jni (much simpler and "customized" than your) but I'm facing a pretty hard problem that maybe you already found and solved. My dataset is composed on many vector tiles so to draw then in multithread I allocate a set of mapnik::Map and I use them to draw the raster tile. The Threads are Java thread calling a jni function that make all the necessary settings and than call mapnik::agg_renderermapnik::image_32 ->apply() and return a bitmap. Now the issue is that apply() is "hanging" (not crashing) for all the threads (after sometimes) except 1. So after sometimes I always have only 1 thread really drawing, so it seems typical Multithread issue, but mapnik is compiled in MULTITHREAD, sqlite3 is compiled in MULTITHREAD, ... Debugging C++ code in Eclipse is nearly impossible so I'm stuck. Do you have any suggestion ? Many thanks for your support.
— Reply to this email directly or view it on GitHub https://github.com/springmeyer/mapnik-jni/issues/8.
Thanks to both of you, I greatly appreciate your support. I'm cross-compiling on MAC OSX 10.10.4, Mapnik 2.3.0, using NDK r10b for Android-19, in IDE Eclipse. I'm cross-compiling Mapnik and all the needed libraries (boost. icu, freetype, ....) with gcc, then I created a cpp wrapper to mapnik in jni to use mapnik in an Android app. Debugging in Eclipse the stack trace show to me only up to the jni wrapper but does not show to me anything "inside" the linked libraries. I know that I could compile mapnik with Debug = true but currently I have linking problems when using this option. Because the exact same source code is cross-compiling for iOS and working without any hang and because I have this hang only in multithread "condition" I was looking for some idea on what to check or how to see the stack trace of the linked mapnik library.
This is to give a better understanding. Now about your suggestion I'm not expert in using gdb from command line, so I don't know if what you suggest gives the same result I'm already having.
I'm by no means enough of an expert on the ndk build environment to be of much help, but I do know people who manage to debug across java and the native code.
I also know that the ndk has done non standard settings and libraries. Mapnik and its dependencies are pretty involved... I wouldn't be surprised if you're hitting a sharp edge that is specific to the android libraries.
You can actually build regular executables with the ndk and run them via adb shell. Have you tried doing that as a test that mapnik on its own is working? It might help factor out the java side of things. On Jul 17, 2015 6:29 AM, "Claudio" [email protected] wrote:
Thanks to both of you, I greatly appreciate your support. I'm cross-compiling on MAC OSX 10.10.4, Mapnik 2.3.0, using NDK r10b for Android-19, in IDE Eclipse. I'm cross-compiling Mapnik and all the needed libraries (boost. icu, freetype, ....) with gcc, then I created a cpp wrapper to mapnik in jni to use mapnik in an Android app. Debugging in Eclipse the stack trace show to me only up to the jni wrapper but does not show to me anything "inside" the linked libraries. I know that I could compile mapnik with Debug = true but currently I have linking problems when using this option. Because the exact same source code is cross-compiling for iOS and working without any hang and because I have this hang only in multithread "condition" I was looking for some idea on what to check or how to see the stack trace of the linked mapnik library.
This is to give a better understanding. Now about your suggestion I'm not expert in using gdb from command line, so I don't know if what you suggest gives the same result I'm already having.
— Reply to this email directly or view it on GitHub https://github.com/springmeyer/mapnik-jni/issues/8#issuecomment-122274892 .
Sorry for the very late reply (I was involved in another project). I understand your suggestion but I'm by far an expert of adb shell and I could "loose" a lot of time only to get it work. I'll try to get a native stack (I'm already sure the thread hang up in the native code).
Thanks for the help I'll update this post when I'll have more info.