With dSYM files and Instruments, there is little cause for iOS developers to manually symbolicate Crash Logs anymore.
However, if you’re a Jailbreak developer, chances are you’ll be compiling dynamic libraries & executables and not apps. This means no Instruments and no dSYM files.
So what do you do when you get an email from Cydia (assuming it’s not blank ofcourse!) with a Crash Log and a disgruntled user who keeps getting SpringBoard crashes after installing your tweak?
Hopefully the log will be symbolicated with Crash Reporter, but this might not be much use. What I would do is take a look and see if I can work out what my code was doing just before the crash. Unfortunately, this is (in my experience) rarely enough to find a crash, unless it’s a fairly obvious mistake.
So you send the user an email thanking them for taking the time to send you the Crash Log and say you’ll do your best to fix it. Trouble is you’re still not sure where to start.
Before dSYM and Instruments, developers used a tool called ATOS. This same tool can come to the rescue now for Jailbreak devs. What ATOS does is converts meaningless stack trace addresses to useful filenames and linenumbers.
To use ATOS to it’s full potential, you’ll need to add the -gstabs compiler flag to your makefile. This will include the extra symbols required to give you line numbers. Without it, ATOS can’t tell you what is causing the problem in any format you will understand (as the relevant symbols will be stripped from the binary). Using the -g compiler flag will keep enough symbols to let ATOS tell you which function was running just before the crash, but it can’t tell you line numbers. It is a good trade off between debugging potential and executable size.
Remember to remove the -gstabs flag before you compile your production build, as the extra symbols massively increase the size of your executable and can apparently cause problems.
If you are compiling with theos/logos, use:
make CFLAGS=-gstabs DEBUG=1
OK so how do you use this magical tool? It’s an easy command line tool:
atos -o [Executable path] -arch armv6 [stack trace address]
For example, from this stack trace:
21 HTCPlugin 0x058ab084 0x5894000 + 94340
The memory address we need is 94340. This stack trace was the last of my code to be called in the crashed thread. This gives us the command:
atos -o [Path to HTCPlugin executable] -arch armv6 94340
This command will then tell me which line of which file was executing just before the crash occured, so I know exactly where to start looking when it comes to debugging the crash.
One final note, the executable you use with ATOS must be exactly the same as the one that created the crash log, or compiled from exactly the same source code. Even a minor difference will cause ATOS to either produce incorrect results or fail to find a line number at all.
Hopefully this will come in useful to some people – Happy Debugging!