SIGSEGV on native tangram

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@[e-mail] (offset 0x1f6a000)

[nebular]

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.

[nebular]

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