I’m getting very close to launch on my game and trying to be diligent about tracking down any and all issues. I’m seeing an occasional crash in my iOS builds that’s not easily reproducible but is caught by Crashlytics. Unfortunately the stack it shows does not include any of my own java code and I’m not sure what to do with it. Here’s the full info on crahlytics:
And the raw stack:
Crashed: Thread-68 0 libsystem_c.dylib 0x1c3d5634 strlen + 28 1 MOE 0x1ae64bd art::Thread::Attach(char const*, bool, _jobject*, bool) + 224 2 MOE 0x1ae64bd art::Thread::Attach(char const*, bool, _jobject*, bool) + 224 3 MOE 0x1aa7d31 art::Runtime::AttachCurrentThread(char const*, bool, _jobject*, bool) + 20 4 MOE 0x19e31e1 art::JII::AttachCurrentThreadInternal(_JavaVM*, _JNIEnv**, void*, bool) + 512 5 MOE 0x1ecf323 nativeToJavaBlockHandler(ffi_cif*, void*, void**, void*) + 198 6 MOE 0x1ed75fd ffi_closure_inner_SYSV + 108 7 MOE 0x1ed50a4 ffi_closure_SYSV + 36 8 Foundation 0x1d537aaf -[NSBlockOperation main] + 146 9 Foundation 0x1d529fa7 -[__NSOperationInternal _start:] + 770 10 Foundation 0x1d5e3cf9 __NSOQSchedule_f + 190 11 libdispatch.dylib 0x1c39659d _dispatch_queue_serial_drain + 854 12 libdispatch.dylib 0x1c38cb71 _dispatch_queue_invoke + 886 13 libdispatch.dylib 0x1c3981b5 _dispatch_root_queue_drain + 326 14 libdispatch.dylib 0x1c39800f _dispatch_worker_thread3 + 106 15 libsystem_pthread.dylib 0x1c53e8ed _pthread_wqthread + 1040 16 libsystem_pthread.dylib 0x1c53e4cc start_wqthread + 8
I know there’s not much to go on here, but I thought I’d post it just in case you guys can make any sense of it, or have any suggestions on how to further track it down. I’m thinking of just playing the game a bunch with the debugger attached in hopes that maybe I catch it on the fly and can find a little more detail on what’s happening.
Thanks for taking a look. The support here on these forums is really top notch!