I was reading a post by Natasha The Robot about Xcode Debug Tips. (must read!) She talks about a WWDC2015 video ‘Advanced Debugging and the Address Sanitizer‘. This shows a really cool trick for debugging. I took Natasha’s advice and I’d like to show you some more tricks of my own to help you with your debugging.
When running a program things can just crash and Xcode and LLDB are not particularly friendly or verbose about it’s error messages. In Xcode you can have two types of breakpoints: ‘Workspace’ and ‘User’. When adding a breakpoint to ‘Workspace’ it is only visible for that project. But wouldn’t it be cool you set your breakpoints once and they show up in every project you create? ⌃-click on the breakpoint and select ‘Move breakpoint to => user’. Now you have that breakpoint in every project you create in Xcode.
In the above video, they talk about adding a breakpoint and printing the first argument. Which is actually the error message. They do this with ‘po $arg1’.
I’ve taken this example and extended it somewhat. Having a error message is nice, but I would also like to see where that error message comes from. One breakpoint is not bound to one action only – you can set up multiple actions when a breakpoint is hit. you can add sounds or backtraces. The later gives us more information about the crash.
⌃-click on the breakpoint and select ‘Edit breakpoint’, now add two actions. The first is a debugger command with ‘po $arg1’. And click the + to add a new action and select debugger command from the pulldown (if not already selected) and type in ‘bt’. This is the LLDB command for ‘backtrace on the current thread’. (More commands for LLDB can be found on their site.). (This should look like the image below)
When compiling again we can actually see where our crash/error is coming from and it a has a more verbose error message.
Happy debugging 🙂