useful xcode debugging methodologies

developing for the iponhe is not a simple thing. cocoa is designed with specific patterns in mind, a dominant model-view-controller, performance oriented with specific ways of going about things. xcode is your best friend, believe it or not. the apple documentation is there for you as well, and many hours were spent to create coherent manuals that will assist us in doing a great job. and doing a great job is a must, because mobile devices are not as browsers. memory foot print is really important. if you over due it, your app will be removed by the OS and UX breaks. bad karma indeed.

dealing with memory leaks and zombies is an important issue, and below i will provide a couple of useful tips to setting up xcode in such a way, and arranging your code, so you have more control and understanding of what’s going on under the hood.

first up, i assume you are familiar with:

– reading a call stack
– play around with the expression window
– use the memory browser when needed

if you are not, you probably should read up on those and play around with them. very useful tools to get the gist of what is going on with your app.

tip #1:
– always archive your dSYM (short for debug symbols) along with the app you send for your QA guys (the “testers”). this is really useful, as once they email you back crash logs (which they will), the data in the log will actually make sense, i.e. the symbols are mapped correctly and you will see actual method names rather than HEX addresses.

tip #2:
use the symbolicatecrash script and pass it the .crash file and .dSYM file. this will allow you to mesh the two together and review what had happened. from the command line, execute ‘find /Developer/ -iname symbolicatecrash’. grab the path and add it to your ~/.profile (if you are a bash kind of a guy). add this line: “PATH=/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/ \
Versions/A/Resources/:$PATH” and don’t forget to “source ~/.profile” before you try and access the script.

tip #3:
enable malloc_error_break so xcode will halt when you double release an object or release a stomped memory. this directive for the debugger is actually a breakpoint. think about it, what we are asking xocde to do, is break on a memory allocation error as if it were a breakpoint (rather than crashing). this is very useful as the program will halt on the line of code that tried to perform the illegal action. add this to your project from the breakpoint view. easy as pie.

tip #4:
party with the zombies. edit your schema (xcode4 people can you hear me?) and add NSZombieEnabled = YES to the “environment variables” list. what happes here is fun. xcode will not release your objects when their reference count is zero, but will keep them for safekeep within the framework of the app. if any of the pseudo released objects is being sent a method, xcode will halt your application, load the debugger and point you to the line of code that tried to access what is suppose to be a zombie. how cool is that? caution! this method is a heavy memory foot print so take it under consideration when you enable them zombies to roam your lands.

on my next post i will show you a nifty header file that allows for fast turning on and off of debug calls from within your app.

good luck!