Since my Twitter complaint about gdb under Xcode suddenly refusing to let me examine symbols, I’ve gotten a lot of search hits on my site for the “unable to access variable xcode” key phrase for my post titled “Unrolled Loops, the Debugger, & YOU“. I figured I’d share a more complete post on the subject of buggered debuggers for the most common causes.
You might see an “unable to access variable” message when using “po” (“print object”) in the debugger console or by hovering over a symbol. Some objects may show nil ( 0×0 ) if you print them or hover over them as well. Even an array might show as non-nil but with zero elements. You might see other messages (which have slipped my mind) as well, but in general Xcode’s helpful GUI debugging elements and even gdb’s console suddenly become most decidedly unhelpful.
The cause is simple: either there are no debugging symbols in your app at the time of debugging or you’ve optimized something somewhere in such a way that the symbols are either gone or don’t make sense.
There’s no universal checkbox that’ll fix this problem for everyone, but there are a limited number of things to check.
By far the most common cause is you’re trying to debug a release build (whose debugging symbols are stripped down to nothing or close to). The resolution for this should be obvious, but in case it’s not, switch to debug, rebuild, then try debugging again.
Project/Target Info Settings
In Xcode 3, project and target build information is complex (I have it on good authority that it’s going to get a bit simpler soonish). There are project- and target-level settings per configuration (as in “Debug” or “Release”). Make sure at all levels under “Debug” configuration that the following conditions are met:
- “Strip Debug Symbols During Copy” is unchecked.
- “Generate Debug Symbols” is checked.
- “Optimization Level” is set to “None [-O0]“.
- “Use Separate Strip” is unchecked.
- “Additional Strip Flags” has nothing set (I don’t think this matters if strip isn’t run).
Basically you want all debug symbols, no optimization, and no stripping (your beta code isn’t mature, and minors shouldn’t be strippers anyway).
Per-File Compiler Flags
This is what bit me. If you “Get Info” on an individual file (like Foo.m) and switch to the Build tab, you’ll notice the largish text box wherein you can place “Additional Compiler Flags for Target…”. Make sure there are no flags here that have anything to do with optimization. In my case, I chose “-O3 -funroll-loops” and this was my problem. Xcode 3 gives you no way to set these per configuration (ie, only use these flags in Release mode). This option was causing loop debugging to become loopy based on how the concept of “loop unrolling” (or unwinding) works.
So … I hope that helps. Feel free to add any other conditions (or corrections) via comments.