android

android copied to clipboard

I am having quite frequent crashes on the native Tangram part. I haven't found a fixed pattern to reproduce them, but along days of development they popup a couple of times every day.

I am using the latest published SDK version with Tangram 5.0, on Android MarshMallow running on a Samsung Galaxy S4.

Maybe what I do quite different to the published examples is to queue map refresh events with the output of an interpolator and android orientation sensors with a very high frequency (around 15 times / sec) in order to get a very smooth map movement.

If you are interested I can post them here as comments on this thread. Please also ask me for any test or additional info you may require. Here is one of them, anyways :)

Keep up the good work!

Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 27153 (GLThread 1596)
03-10 17:18:08.107   251   251 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-10 17:18:08.107   251   251 F DEBUG   : CM Version: '13.0-20160820-SNAPSHOT-ZNH5YAO0J3-jfltexx'
03-10 17:18:08.107   251   251 F DEBUG   : Build fingerprint: 'samsung/jfltexx/jflte:5.0.1/LRX22C/I9505XXUHOJ2:user/release-keys'
03-10 17:18:08.107   251   251 F DEBUG   : Revision: '0'
03-10 17:18:08.107   251   251 F DEBUG   : ABI: 'arm'
03-10 17:18:08.107   251   251 F DEBUG   : pid: 27048, tid: 27153, name: GLThread 1596  >>> tv.nebular.mapzentest <<<
03-10 17:18:08.107   251   251 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8
03-10 17:18:08.166   251   251 F DEBUG   :     r0 00000000  r1 9f19c408  r2 a6122877  r3 00000000
03-10 17:18:08.167   251   251 F DEBUG   :     r4 92282680  r5 928a14f0  r6 00000001  r7 98e72378
03-10 17:18:08.167   251   251 F DEBUG   :     r8 00000000  r9 9f19c408  sl a9d6fdb0  fp 00004000
03-10 17:18:08.167   251   251 F DEBUG   :     ip 992e75f0  sp 98e72350  lr 9903bc6d  pc 990811ba  cpsr 80030030
03-10 17:18:08.175   251   251 F DEBUG   :
03-10 17:18:08.175   251   251 F DEBUG   : backtrace:
03-10 17:18:08.176   251   251 F DEBUG   :     #00 pc 001681ba  /data/app/tv.nebular.mapzentest-1/lib/arm/libtangram.so (_ZN7Tangram15DynamicQuadMeshINS_12SpriteVertexEE4drawERNS_11RenderStateERNS_13ShaderProgramEi+141)
03-10 17:18:08.176   251   251 F DEBUG   :     #01 pc 0016810f  /data/app/tv.nebular.mapzentest-1/lib/arm/libtangram.so (_ZN7Tangram10PointStyle16onBeginDrawFrameERNS_11RenderStateERKNS_4ViewERNS_5SceneE+72)
03-10 17:18:08.176   251   251 F DEBUG   :     #02 pc 0010f331  /data/app/tv.nebular.mapzentest-1/lib/arm/libtangram.so (_ZN7Tangram3Map6renderEv+648)
03-10 17:18:08.176   251   251 F DEBUG   :     #03 pc 0082f3db  /data/app/tv.nebular.mapzentest-1/oat/arm/base.odex (offset 0x604000) (void com.mapzen.tangram.MapController.nativeRender(long)+94)
03-10 17:18:08.176   251   251 F DEBUG   :     #04 pc 00832113  /data/app/tv.nebular.mapzentest-1/oat/arm/base.odex (offset 0x604000) (void com.mapzen.tangram.MapController.onDrawFrame(javax.microedition.khronos.opengles.GL10)+422)
03-10 17:18:08.176   251   251 F DEBUG   :     #05 pc 7298fcc1  /data/dalvik-cache/arm/system@[email protected] (offset 0x1f6a000)

Hi @nebular, thanks for the report. Your use case does sound a little unusual but we should still avoid crashing in this scenario. Two things:

1. Is the backtrace of the crash the same every time?
2. Can you elaborate on what you mean by "queue map refresh events" or share example code?

Thanks

Hi @matteblair

1. I will pay attention from now on, about where does it crash, I think it's always on maprender, but I am not sure at the moment.

2. My activity has a callback "onAzimuth()" that gets called with the phone orientation sensor updates. I use the current azimuth value to rotate the map continuously. Please check the enclosed short video to get an idea.

Regards.

VID-20170310-WA0000.mp4.zip

Hmm got another crash in the exact same place. However I just found a pattern that suggests it may not be related to the continuous render... It crashes (sometimes) just after I request a route, paint it and change UI to routing mode (lots of stuff synchronous and asynchronous), so I suspect it might be something related to threads ... Yesterday I discovered that (some?) Route Engine callbacks are triggered from a worker thread, so I needed to post widget updates to the UI thread in order to avoid some disasters. Let me check this in-depth and i'll report back.

After more tests, I think the above message is not really the root issue, and just a coincidence, besides, checked all interacting with the map is done from the UI thread, and all map updates are posted via map.queueEvent().

I am having more crashes like this one. It's not very deterministic, sometimes I can be using the app for 2 hours, navigation, tilt change, easing, adding and removing route polys, etc... while others it crashes in a matter of minutes.

Good thing is, it looks like it always crashes at the same point, (Tangram/DynamicQuadMesh/SpriteVertex/draw/RenderState/ShaderProgramEi+1XX)

Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 20011 (GLThread 1069)
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
03-12 13:19:59.125   249   249 F DEBUG   :     r0 92e1fcc0  r1 a8a31008  r2 00000001  r3 00000001
03-12 13:19:59.125   249   249 F DEBUG   :     r4 8f754960  r5 92e1fcc0  r6 00000001  r7 93f3f378
03-12 13:19:59.125   249   249 F DEBUG   :     r8 00000000  r9 a8a31008  sl 9277dda0  fp 00004000
03-12 13:19:59.126   249   249 F DEBUG   :     ip 98dd75f0  sp 93f3f350  lr 98b711c3  pc 00000000  cpsr 80030030
03-12 13:19:59.191   249   249 F DEBUG   :
03-12 13:19:59.191   249   249 F DEBUG   : backtrace:
03-12 13:19:59.191   249   249 F DEBUG   :     #00 pc 00000000  <unknown>
03-12 13:19:59.191   249   249 F DEBUG   :     #01 pc 001681c1  /data/app/tv.nebular.mapzentest-2/lib/arm/libtangram.so (_ZN7Tangram15DynamicQuadMeshINS_12SpriteVertexEE4drawERNS_11RenderStateERNS_13ShaderProgramEi+148)
03-12 13:19:59.191   249   249 F DEBUG   :     #02 pc 0016810f  /data/app/tv.nebular.mapzentest-2/lib/arm/libtangram.so (_ZN7Tangram10PointStyle16onBeginDrawFrameERNS_11RenderStateERKNS_4ViewERNS_5SceneE+72)
03-12 13:19:59.192   249   249 F DEBUG   :     #03 pc 0010f331  /data/app/tv.nebular.mapzentest-2/lib/arm/libtangram.so (_ZN7Tangram3Map6renderEv+648)
03-12 13:19:59.192   249   249 F DEBUG   :     #04 pc 00834683  /data/app/tv.nebular.mapzentest-2/oat/arm/base.odex (offset 0x609000) (void com.mapzen.tangram.MapController.nativeRender(long)+94)
03-12 13:19:59.192   249   249 F DEBUG   :     #05 pc 008373bb  /data/app/tv.nebular.mapzentest-2/oat/arm/base.odex (offset 0x609000) (void com.mapzen.tangram.MapController.onDrawFrame(javax.microedition.khronos.opengles.GL10)+422)
03-12 13:19:59.192   249   249 F DEBUG   :     #06 pc 7298fcc1  /data/dalvik-cache/arm/system@[email protected] (offset 0x1f6a000)

Whatever additional info you might need, please ask!

@nebular thanks for the update. This non-determinism smells like a multi-threading issue to me. I'll take a look into this call path when I have a chance. I don't suppose you have a code sample that reproduces this crash, do you? :)

Unfortunately I don't have it yet! But If I manage to narrow down the issue, or get frequent crashes I will keep you updated.

Since I stopped changing a marker bitmap in every frame (I used that before I knew how to update styles for the markers) this issue does not seem to happen anymore.

Is it ok to close this issue now?

@nebular you'll also be happy to know we are currently working on adding first class support for Tangram bitmap markers in the Mapzen Android SDK.

https://github.com/mapzen/android/issues/189

@ecgreb Sure, close it, it wouldn't harm to take a look at the place where it was crashing, though... I was replacing the bitmap like 20 times per second, but it's nothing illegal anyways ;)

I'm more than happy to hear about the first-class support for markers, I really love the power of the styles (tinting the bitmaps specially).