With dSYM files and Instruments, there is little cause for iOS developers to manually symbolicate Crash Logs anymore.<\/p>\n
However, if you\u2019re a Jailbreak developer, chances are you\u2019ll be compiling dynamic libraries & executables and not apps. This means no Instruments and no dSYM files.<\/p>\n
So what do you do when you get an email from Cydia (assuming it\u2019s not blank ofcourse!) with a Crash Log and a disgruntled user who keeps getting SpringBoard crashes after installing your tweak?<\/p>\n
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\u2019s a fairly obvious mistake.<\/p>\n
So you send the user an email thanking them for taking the time to send you the Crash Log and say you\u2019ll do your best to fix it. Trouble is you\u2019re still not sure where to start.<\/p>\n
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.<\/p>\n
To use ATOS to it\u2019s full potential, you\u2019ll 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\u2019t 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\u2019t tell you line numbers. It is a good trade off between debugging potential and executable size. If you are compiling with theos\/logos, use:<\/strong> OK so how do you use this magical tool? It\u2019s an easy command line tool: For example, from this stack trace: 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: 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.<\/p>\n 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.<\/p>\n Hopefully this will come in useful to some people \u2013 Happy Debugging!<\/p>\n","protected":false},"excerpt":{"rendered":" With dSYM files and Instruments, there is little cause for iOS developers to manually symbolicate Crash Logs anymore. However, if you\u2019re a Jailbreak developer, chances are you\u2019ll 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 … Continue reading ATOS for Debugging CrashLogs<\/span>
\n 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.<\/strong><\/p>\n
\nmake CFLAGS=-gstabs DEBUG=1<\/code><\/p>\n
\natos -o [Executable path] -arch armv6 [stack trace address]<\/code><\/p>\n
\n21 \u00a0HTCPlugin 0x058ab084 0x5894000 + 94340<\/code><\/p>\n
\natos -o [Path to HTCPlugin executable] -arch armv6 94340<\/code><\/p>\n