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>]
Debugging application using IDE is fast and easy, but most of the times during my professional jobs I had to debug application on some server placed on the other part of the globe. I tried to use some methods for remote debugging, but I didn’t found one that would be efficient and fast enough to work smoothly.
I am also the guy that likes to do most of the things in text console (I have something from geek:) ). In such situation I will shortly present tools that I found pretty much useful.
GNU Debugger. Probably all you who have ever done some debugging on linux know this tool. Nothing more to say, you just have to know it.
It’s terminal application that is a little similar to vim text editor by means of display and key bindings. It’s based on gdb, but it has one feature that is really helpful for me. The main window is divided in two parts: upper and lower one. The upper one presents the source code of currently debugging application, and the lower one is just the same as the window from the gdb.
You can see current line marker (green arrow), breakpoint (line number marked in red) and source code lines before and after the current one. To switch from lower window (which is the default) to the source code window you just press ESC button. To get back to the gdb window, press “i” button (like entering insert mode in vim).
When you are in source code window, you can move the code up and down using arrows (or j and k keys like in vim). You can also search strings by typing “/”. Pressing space will create or delete breakpoint (if there was any) in the current line.
Prints a stack trace of running processes. This tool helped me couple of times when I had to debug multithreaded application that are already started, because it prints stack trace of each thread in the process. When an application hangs because of i.e. wrongly used locks, you can use it. It prints similar output to the gdb one (with gdb you have to attach to the currently running process and print information about threads “i th”), but is just faster to type: “pstack <pid>”.
Traces the system calls of the program. It will help you when you are trying to find out what system calls are used by the program. I haven’t used it much but I saw when my teammate solve a very hard to find problem in a second after using it.