Question: Why does lldb insist on printing the wrong data — the value of the first ivar, no matter which ivar I ask for? This is Xcode 5.1.1. And yes, I am compiling with -O0, symbols not stripped, etc.

`(lldb) print *self
 (SMTestHarness) $13 = {
 NSObject = {
 isa = SMTestHarness
 }
 _dir = 0x00740520 @"/Users/lc/Projects/servermonitor/Test/unit-test"
 _ip = 0x007406b0
 _domain = 0x007429f0
 _sm = 0x00676900
 _state = 0x00741980
 _dsaSimulators = 0x00741d10 5 key/value pairs
 _timers = 0x00741f50 2 objects
 _originalWd = 0x007403f0 @"/Users/lc/Projects/servermonitor/Test"
 }
 (lldb) print _dir
 (NSString *) $14 = 0x00740520 @"/Users/lc/Projects/servermonitor/Test/unit-test"
 (lldb) print _ip
 (IPAddress *) $15 = 0x00740520
 (lldb) print _domain
 (FirstPointDomain *) $16 = 0x00740520
 (lldb) print _sm
 (ServerMonitorCrashTestDummy *) $17 = 0x00740520`

Interestingly, the variable display in the left-hand pane is correct; it's only print commands in the lldb console that are wrong.

Answer: 
The variables view in Xcode doesn't use the lldb expression parser (i.e. the `print` command.) Mainly this is because it would be very inefficient to have to parse expressions for each local variable & its subelements every time you step. And even without this, a full-on expression parser is way more fire power than you need for the task of dumping local variable values.

Instead, lldb has another sub-system just for dumping the contents of variables (no calling functions or complex expressions, just printing values.) From command-line lldb, you can get at that subsystem with the `frame variable` command. 

That bit of trivia probably doesn't help you much, but it is why you can get different results from "print" which runs the fully general expression parser and the Xcode locals view...

What you are seeing, however, is that the lldb expression parser isn't getting the value of the offsets of individual ivars within their containing ObjC object right. The expression parser thinks all the ivars are at 0 offset from the object start - which is in fact what your example shows. And more particularly - from the example you included - this happens when debugging a 32 bit app using the 1.0 version of the Objective C Runtime. 

That's a long-standing bug in lldb. 

There isn't a good workaround if you have to debug ObjectiveC 1.0 32-bit x86 apps. If you have a 32 bit only machine, then you are pretty much stuck here, and have to use `frame var`. But if you have a 64-bit capable machine, unless there's some very compelling reason to debug the 32 bit fork of the app, you can just switch to debugging the 64 bit version of the app instead, and this problem should go away.

Note, though the iOS simulator runs 32 bit code, it uses the ObjectiveC 2.0 runtime, and doesn't have this bug.
If you are printing objects use the "po" (print object) command.