Version: 2019.1 (switch to 2018.3 or 2017.4)
Mobile Developer Checklist
Profiling
Other Versions

Crashes

Checklist for crashes

  • Disable code stripping (and set “slow with exceptions” for iOS)
  • Follow the instructions on Optimizing the Size of the Built iOSApple’s mobile operating system. More info
    See in Glossary
    Player (iphone-playerSizeOptimization) to make sure your game does not crash with stripping on iOS.
  • Verify it is not because of out of memory (restart your device, use the device with maximum RAM for the platform, be sure to watch the logs)

Editor.log - on the editor

The Debug messages, warnings and errors all go to the console. Also Unity prints status reports to the console - loading assetsAny media or data that can be used in your game or Project. An asset may come from a file created outside of Unity, such as a 3D model, an audio file or an image. You can also create some asset types in Unity, such as an Animator Controller, an Audio Mixer or a Render Texture. More info
See in Glossary
, initializing mono, graphics driver info.

If you are trying to understand what is going on look at the editor.log. Here you will get the full picture, not just a console fragment. You can try to understand what’s happening, and watch the full log of your coding session. This will help you track down what has caused Unity crash to crash or find out what’s wrong with your assets.

Unity prints some things on the devices as well; Logcat console for Android and Xcode gdb console on iOS devices

Debugging on Android

  1. Use the DDMS or ADB tool
  2. Watch the stacktrace (Android 3 or newer). Either use c++filt (part of the ndk) or the other methods, like: http://slush.warosu.org/c++filtjs to decode the mangled function calls
  3. Look at the .so file that the crash occurs on:
    1. libunity.so - the crash is in the Unity code or the user code
    2. libdvm.so - the crash is in the Java world, somewhere with Dalvik. So find Dalvik’s stacktrace, look at your JNI code or anything Java-related (including your possible changes to the AndroidManifest.xml).
    3. libmono.so - either a Mono bug or you’re doing something Mono strongly dislikes
  4. If the crashlog does not help you can disassemble it to get a rough understanding of what has happened.
    1. use ARM EABI tools from the Android NDK like this: objdump.exe -S libmono.so >> out.txt
    2. Look at the code around pc from the stacktrace.
    3. try to match that code within the fresh out.txt file.
    4. Scroll up to understand what is happening in the function it occurs in.

Debugging on iOS

  1. Xcode has built in tools. Xcode 4 has a really nice GUI for debugging crashes, Xcode 3 has less.

  2. Full gdb stack - thread backtrace all

  3. Enable soft-null-check: Enable development buildA development build includes debug symbols and enables the Profiler. More info
    See in Glossary
    and script debugging. Now uncaught null ref exceptions will be printed to the Xcode console with the appropriate managed call stack.

  4. Try turning the “fast script call” and code stripping off. It may stop some random crashes, like those caused by using some rare .Net functions or reflection.

Strategy

  1. Try to figure out which script the crash happens in and debug it using mono develop on the device.
  2. If the crash seems to not be in your code, take a closer look at the stacktrace, there should be a hint of something happening. Take a copy and submit it, and we’ll take a look.

Did you find this page useful? Please give it a rating:

Mobile Developer Checklist
Profiling