Help deciphering a crash

Support
1

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!

Paul

2

Dear Paul,

It seems that you have a problem on adding fabric crash reporter.
Please follow this post it really worked and so helpfull

I hope u find the way.

Regards,
Saeed.

3

Hi Saeed -

Thanks for the reply, but actually Fabric is working great for me. Most of the crash reports I get in Fabric actually include a java stack and have been very helpful in tracking down errors. Only this one crash I linked above does not. I’m guessing that means this particular crash is lower level, perhaps in the MOE code itself, which is why I posted it here.

Paul

4

Hi Paul,

the first step to debug such issues is to build a debug SDK. You should find the instructions to do it here and here. Then you can create a moe.sdk.localbuild file into your iOS module with simply the path to your locally built SDK inside it. When the Gradle plugin sees this file, it will use it instead of the downloaded SDK.

For example, mine looks like this:

/path/to/moe/checkout/moe/tools/moe.sdk.publisher/build/dev-sdk

Then you can use the strategy you described to try and catch the crash inside Xcode.

Best Regards,
Gergely

1 Like