Useful crash detection in production IL2CPP builds

Hi there,

Is there any solution for getting useful remote crash information out of production IL2CPP builds?

At the moment I’ve plugged Crashlytics into our game and this is working fine enough for development builds, but when doing a production build I imagine we’re going to end up with unreadable method and type names throughout. Is there some kind of a mapping that can be used to reverse these substitutions if a crash is made in a production build? Or something else?

We’re hoping to launch for iPad at the end of the month and launching with useful remote crash logging is pretty hugely desirable.

Thanks for any tips!

You can get crash reports directly into Xcode 6.3 or later directly from TestFlight beta or production.

https://developer.apple.com/library/prerelease/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AnalyzingCrashReports/AnalyzingCrashReports.html

This only works for the users who accepted to share their data with you.

Otherwise you can for example ask users to send you crash reports.

We’re using HockeyApp: http://hockeyapp.net/

I found it a lot easier to implement than Crashlytics and more reliable. It’s open source and people have already made Unity plugins, so it makes it that much easier to implement. If you upload from dsym you should get good crash reports during production.

OK, thanks guys. I’ll have a look into those and one of these mechanisms should solve the delivery problem.

As for the reporting of useful information from IL2CPP production builds, does uploading the dSYM work around this? I thought that the C++ brought into Xcode itself doesn’t have method and type names based on the IL code, so that the crash information generated using the dSYM file still wouldn’t be useful?

i.e. at the moment I have Crashlytics working which has produced some useful crash information from IL2CPP development builds, but I presumed from production builds the dSYM file will have C++ method and type names that aren’t based on my IL names.

Maybe I’m wrong though, can anyone shed light on this?

Actually, what were the reliability issues you were seeing with Crashlytics? Was this recently? Maybe there’s a chance it could’ve been resolved since. As I’ve got Crashlytics hooked in and HockeyApp has extra cost involved it’d be good to know it’s going to be worth the change.

I’ll do some more looking into TestFlight too.

@cheywood

Yes, if you don’t use a development build, then the type and method names in IL2CPP will be mangled to minimize the generated C++ code. I’ve not thought about how this will impact crash reporting though, it might be nice to add an option to allow you to use the same names as the IL.

Does anyone else have opinions one way or another on this?

I think having an option to allow use of the IL names would be very useful!

Me too!

If we were wanting to keep the type and method name mangling but want to be able to get some kind of use out of crash reports could there be a file produced from the IL2CPP process logging the mapping between original IL method and type names and generated C++ names? Is this currently possible in any form?

My apologies, I was incorrect in my earlier post. For an iOS build with IL2CPP and a non-development player, the type and method names in C++ are the same as they are in IL, so crash reporting should be fine.

Only the WebGL target builds with different type names. You can verify this by looking at the command line for il2cpp.exe during the build process. The “–output-format=Compact” flag indicates that the type names will be mangled.

At some point in the past we were passing this flag for iOS builds as well, but it is no longer passed. Please let me know if anyone is seeing different behavior from this, and sorry for the confusion on my part!

Oops, I must have totally been basing this off a previous version then! I’d remembered seeing the mangled names in the past but then I must have missed this update in the changelog. Actually, I think that was with 5.1.something, I’m seeing the desired behaviour here with 5.0.2f1.

Thanks for helping clear that up Josh!

@CPXTom

On the capture & delivery part of my problem could you tell me any more about the reliability issues you were seeing with Crashlytics CPXTom? And how recent a version that was?

@cheywood
This was a few months ago, don’t remember which version, but it was the current version at the time. My main gripes were no Unity integration (I had to do this myself) and the fact that it did not show crash reports if they can’t be symbolicated. I get that they’re pretty much useless if they aren’t, but it was hard to tell if it was working properly, since I didn’t see anything coming in.
Also the install process is a bit too hand holdy for me, and actually made it a bit difficult to automate. Seemed to take a long time to symbolicate as well after I uploaded a dsym.

@CPXTom
OK that’s great; thanks a bunch for taking the time to explain!