Debugging in Objective C

I found a better way description of debugging in Xcode in a site
http://www.fiveminutes.eu/debugging-objective-c-code/

So i am just pasting that site matter here, for the reference.

Xcode development environment is integrated with GDB (GNU Debugger), a cross-platform debugger supporting many languages including C/C++, Fortran and Objective C. Xcode provides user interface for tasks as managing breakpoints or inspecting variables. For all advanced tasks there is the GDB command line. Command line provides commands for controlling all aspects of program execution and data manipulation.

Most common commands are:
- print - prints the variable or function result value

(gdb) print self.imageView  #show the value of imageView member
(gdb) print -[self description]  #execute [self description] and show the result

NOTE: executing code can change the state of current object or application and lead to unexpected results

- po - print object, command introduced in Objective C debugging and used to print out useful information about selected object (that object can be a result of code execution, as for print). _NSPrintForDebugger method will be called on object to retrieve description. All po-able objects must implement this method.

(gdb) po -[NSString stringWithString:@"This is a test."]
This is a test.

- call - calls a function or method and stores the returned result.

(gdb) call (NSString*)[NSString stringWithString:@"Another test."]
$1 = (NSString *) 0x5e21120
(gdb) po $1
Another test.

- bt - show call stack
- cont - continue execution
- next - execute next line
- step - execute next line with stepping into functions
- kill - stop execution

NSLog(NSString* format, …) function is useful for printing out information in the debugger console. NSLog is useful for outputting intermediate results in algorithms or loops where breakpoint usage is not practical. From iOS 4.0 and Mac OS X 10.6 it is possible to use [NSThread callStackSymbols] to get the call stack and monitor the execution flow from code.

Applications sometimes crash because access has been made to an object that has already been freed (and memory possibly reallocated). Best practice to debug such problems is enabling zombie objects by setting the NSZombieEnabled environment variable to YES. When zombies are enabled, all deallocated objects will not be freed, but instead turned into _NSZombie objects. Latter access to a _NSZombie object will trigger a breakpoint and help in tracing the zombie’s origin. No object is freed in this mode and memory consumption can skyrocket and cause application crashing on iPhone or swapping on personal computer. CFZombieLevel environment variable can be used to fine-tune zombie behavior.

Xcode also provides static analysis tool and profiler for catching performance bottlenecks, memory leaks and all other sorts of problems.