Home > game development, unity > Demystifying Unity iOS Crash Logs

Demystifying Unity iOS Crash Logs

Someone who never ported Unity game to mobile (iOS / Android) can tell that it’s pretty easy. If you think so, you are very wrong. When running i.e. WebPlayer version of your game it allows you throwing exceptions that are not caught and sometimes the game runs without any crash, only in the log file you can read note about it. Mobile version is less forgiving. Unhandled exception will crash your app.

Reading iOS crash logs helps a lot while debugging, but if they are still mystery for you, you can read great article about them here: Demystifying iOS Application Crash Logs. The problem is, that sometimes Unity creates crash on your iOS device that will not tell you much:

6 mygame 0x002328f4 ___lldb_unnamed_function7016$$mygame + 268
7 mygame 0x0122597c ___lldb_unnamed_function93440$$mygame + 200
8 mygame 0x01964224 ___lldb_unnamed_function136404$$mygame + 2152
9 mygame 0x01a06274 ___lldb_unnamed_function138276$$mygame + 132
10 mygame 0x015a08cc MonoBehaviour::InvokeMethodOrCoroutineChecked(ScriptingMethod*, MonoObject*, MonoException**) (MonoUtility.h:452)
11 mygame 0x015a0918 MonoBehaviour::InvokeMethodOrCoroutineChecked(ScriptingMethod*, MonoObject*) (MonoBehaviour.cpp:975)

It will tell you nothing because of ___lldb_unnamed_function (sometimes there is only memory address if automatic symbolication went totally crazy). Instead of this unnamed function you would like to see name of your method in your C# scripts. The problem is wrong calculation of method address by default Xcode symbolication tool (more details about these calculations you can find here). To ease you life I created a script that will symbolicate crash log for you. All you need is the archive from which you created your binary, name of the application and crash log itself.

Usage is as follows:

symbolicate_crash.sh <archive> <app_name> <crash_log> [<output_file>]

<output_file> is optional, if you will not specify it, script will symbolicate crash log in file with the name same as the crash log, but with additional postfix. Instead of <crash_log> you can put directory that contains crashes and all of them will be symbolicated one after another.

Here is the usage example:

symbolicate_crash.sh "Unity-iPhone 3-20-14 4.17 PM.xcarchive/" mygame "mygame 3-20-14 5-11 PM.crash"

Now the crash log will look more user friendly:

6 mygame 0x002328f4 m_Facebook_IOSFacebook_OnRequestComplete_string (in mygame) + 268
7 mygame 0x0122597c m_wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr (in mygame) + 200
8 mygame 0x01964224 mono_jit_runtime_invoke (in mygame) + 2152
9 mygame 0x01a06274 mono_runtime_invoke (in mygame) + 132
10 mygame 0x015a08cc MonoBehaviour::InvokeMethodOrCoroutineChecked(ScriptingMethod*, MonoObject*, MonoException**) (in mygame) (MonoUtility.h:452)
11 mygame 0x015a0918 MonoBehaviour::InvokeMethodOrCoroutineChecked(ScriptingMethod*, MonoObject*) (in mygame) (MonoBehaviour.cpp:975)

I have a dream that one day I rewrite this script in some more readable form switching to python maybe, but for now it should solve at least some of your Unity iOS crash log problems.

Happy bugs hunting!

  1. froschmedia
    September 26, 2014 at 18:23

    Zbyhoo, this script looks like it could be a lifesaver as we have a live product experiencing crashes, but I’m having some trouble getting it to work for us. See my post here and any thoughts on how I might be able to use it would be greatly appreciated:

    • September 26, 2014 at 22:30

      I’ve made a mistake, correct usage is the one in example, and should be:
      symbolicate_crash.sh archive app_name crashlog

      Already fixed, thanks!

  2. mbeard8906
    September 30, 2014 at 21:58

    If you replace some of the script with the following, then you shouldn’t need to hard code anything like it is now!

    export xcodepath=$(xcode-select -print-path)
    export symbolicatecrash_app=$(find $xcodepath -name symbolicatecrash -type f)
    export DEVELOPER_DIR=`xcode-select -print-path`

    The replacement for the symbolicatecrash comes from the following url: https://github.com/robovm/robovm/wiki/Symbolicate-a-crash-reports and seems to work just fine, as long as the following command returns something:

    find `xcode-select -print-path` -name symbolicatecrash -type f

    I’ve had a couple of machines where Xcode 6 has been installed, but it doesn’t have the symbolicatecrash tool anywhere in Xcode. I have other machines where it works just fine. It’s usually the older machines where multiple versions of Xcode have been installed before Xcode 6. The ones that usually don’t return anything have only had Xcode 6 installed.

    The DEVELOPER_DIR is from the same article and I’ve not had that work on any machine, so it should be really solid!

    Thanks for sharing your script! It’s really awesome! Hopefully, this will make it more resilient for future changes from Apple!

    Thanks again!

    • September 30, 2014 at 22:15

      Thanks a lot for your improvements! I already applied them to my scripts.

  3. mbeard8906
    October 1, 2014 at 19:43

    Also, found out where the symbolicatecrash is for Xcode 6, as per https://stackoverflow.com/questions/25769775/symbolicatecrash-from-xcode-6-gm/26148021#26148021. In short, it is at:


    Just found this this, so thought I’d share!

  4. mbeard8906
    October 1, 2014 at 19:44

    That seemed to cut off the path, so here it is again:



    • mbeard8906
      October 1, 2014 at 19:46

      ok, that still didn’t seem to work, so …


      just append the two lines together and you should be good!

  5. mbeard8906
    October 1, 2014 at 20:26

    One more chime in that will allow whether you’re using Xcode 5 or Xcode 6 work correctly, which, btw, allows my machine which wasn’t working to work.

    If you put the following in (replacing as necessary), it does it up quite well:

    export DEVELOPER_DIR=$(xcode-select -print-path)
    export DEVDIR=${DEVELOPER_DIR%/*}
    export symbolicatecrash_app=$(find $DEVDIR -name symbolicatecrash -type f)

    the second statement basically drops off the last directory from the path and should give you something like /Applications/Xcode.app/Contents, which seems to work fine with the find for symbolicatecrash and might take just a little more time to find, but …

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: