Archive for the ‘Xcode’ Category

Protected: Mobile Tech Talks 11.09.2014

Thursday, September 11th, 2014

This content is password protected. To view it please enter your password below:

Xcode & Breakpoints

Friday, November 29th, 2013

Just some things you might already know and some not:

The most common way of adding breakpoints in Xcode is to just enable them by clicking on the left side in the Code editor.

Screen Shot 2013-11-29 at 06.50.35

In the breakpoint navigator (Cmd+7) you can now see your breakpoint – and possibly more breakpoints you already added. If you click it again, you will disable it. To remove it, delete it from the navigator or drag & drop it away to trash it. So much for the obvious part.

Now there’s so much more you can do with breakpoints. First of all, breakpoints can be in different scopes:

  • Workspace
  • User (Global)
  • Project

Just right click it and select “Move Breakpoint to”. If you move it to “User”, it will show up in all your Xcode projects or workspaces you open with your current user.

The most common “User”-scope breakpoint is the symbolic breakpoint to objc_exception_throw in libobjc.A.dylib.

Now if you right-click again and click “Edit Breakpoint…”, you will start to scratch the surface of the world of breakpoints. You can execute scripts, debugger or shell commands, log messages or even play a sound (w00t!). Keep in mind, that whatever you do there will interrupt the execution of your application until whatever you selected here is finished. A typical debugger command you might want to execute is bt which will show a backtrace (call hierarchy) at the current position in code.

Next, another powerful feature is symbolic breakpoints. You can add symbolic breakpoints to object-specific symbols (-[UIViewController viewWillAppear]) or even just symbols (viewWillAppear). Just try it and you will suddenly get insight to a huge bunch of internal object classes you never heard of. The latter will break your execution each time any object receives the viewWillAppear message.

Next, watch points. In some situations you might wonder why some property or object value changes and you just don’t understand why. No problem, just add a watch point to that property! Just use any breakpoint to pause execution of you app and take a look at the Debug area.

Screen Shot 2013-11-29 at 07.09.29

Right-click any of the variables you see there and select Watch. From now on, every time the variable changes, your app will be interrupted. Keep in mind, that variables change when non-object types change (like an NSInteger increases) or object pointers change. For example, appending something to a NSMutableString does not change the object pointer, so the watchpoint will not fire. By default, watch points will fire on “write”, however you can also watch reads. Watchpoints will show up in the Breakpoint Navigator too.

Every time your app gets interrupted, you can also use the debug console (lldb by default) and write what we just did as a command there. This is much more powerful as you can do even more there. Just take some time and read the command documentation

If you are already familiar with gdb and want to know how you do the same with lldb there’s a nice GDB to LLDB command map.

Happy debugging!