Tuesday, April 12, 2011

Using atos for reading crash logs

If I get a crash log from a user, it's no problem investigating the cause since I use XCode's "build & archive" feature to save the symbol (dSYM) files before submitting the app to iTunes. Just drag and drop the crash log into the Device Logs section of XCode and the "symbolicator" translates the memory addresses in the crash log back into code references. Easy.

However, I don't normally use Build & Archive for sending ad hoc builds to testers, so when a crash log is reported, symbolication becomes more challenging. (and impossible if the .dsym file has been deleted or overwritten) I've used symbolicatecrash previously but with various levels of success. (now that I think about it, actually just one level of success: it runs the program without error but doesn't translate the symbols)

While I was investigating what to do about this, I ran across a couple of web posts here and here that talked about using atos (address to symbol)

Unfortunately, neither post by itself worked for me, however a combination did. Basically the magic was this (most of this is in the first post referenced above):

1. Open up the crash log
2. Determine which thread crashed
3. Look for the first entry in that thread that references your application, it'll look something like the third line below:

3 UIKit 0x3230da20 0x3223a000 + 866848
4 UIKit 0x3230d97c 0x3223a000 + 866684

5 MikesCrashingApp 0x000176d8 0x1000 + 91864

4. Copy the .app, the crash log, and the .dSYM into a directory, and then open a terminal and CD into that directory
5. Run the atos command and use the address from the line in the crash log. The atos command should look something like:

atos -arch armv7 -o MikesCrashingApp.app/MikesCrashingApp 0x000176d8

If all works as expected, you should see a response like:

-[MyViewController tabBar:didSelectItem:] (in MikesCrashingApp) (MyViewController.m:79)

Which will at least tell you where the app died.

Perhaps I should just start using build and archive for adhoc builds too. :)

Sunday, April 3, 2011


I'm generally pretty good about tracking down EXC_BAD_ACCESS errors but I had one tonight that really got me going. Seems that sometimes I was switching UIWebView windows too fast and the delegate was being called after the UIWebView was already dealloc'd. Once I cleared the delegate before releasing, all was well.

I probably would still be looking for this problem were it not for this site which suggested the following:

Go to "Targets" tab, open "Executables" and add the following environment variables with values set to "YES" (sans quotes)


As soon as it detects any activity with with the zombie it'll throw an exception. For more info, you can also run the gdb command: shell malloc_history <pid> <address> - in my case it was a buttload o' crap, but at least it indicated that the problem was related to a delegate.

Definitely one for the saveme.txt file.