lldb fails to print variable values with "error: reference to 'id' is ambiguous"

Question

Since I updated to xcode 4.3 and let it switch my debugger over to lldb, any request to print a member variable fails with this error message:

(lldb) print request
error: error: reference to 'id' is ambiguous
note: candidate found by name lookup is 'id'
note: candidate found by name lookup is 'id'
error: 1 errors parsing expression

'self' is ok:

(lldb) print self
(LoginViewController *) $6 = 0x1cd54d50

And other forms of printing the member variable also fail:

(lldb) print self.request
error: property 'request' not found on object of type 'LoginViewController *'; did you mean to access ivar 'request'?
error: 1 errors parsing expression
(lldb) print self->request
error: error: reference to 'id' is ambiguous
note: candidate found by name lookup is 'id'
note: candidate found by name lookup is 'id'
error: 1 errors parsing expression

Everything else otherwise seems to be working fine. Xcode's variable window can correctly retrieve the value. I've tried a clean build and deleting ~/Library/Developer/Xcode/DerivedData/. Googling hasn't revealed any other instances of the same problem.

I found one thread on Apple's dev forum but no solution:

https://devforums.apple.com/message/623694

I've reported this to Apple as Bug ID# 11029004.

Flabby

lldb is still a work-in-progress. – Levileviable

@Zaph I wonder why Apple made it the default debugger in XCode 4.3 if that's the case. – Flabby

For some reason the ability to display ivars in the debugger has a low priority at Apple. Many times ivars that are created auto-created by @property statements or declared in the @implementation are not displayable. Things are getting better albeit slowly. Please file a bug at bugreport.apple.com. – Levileviable

I have the same problem, but only in my main project, not in a freshly generated project. Haven't figured out what it could be... Libraries? C++? – Executor

For lldb to be the default debugger in Xcode 4.3, yet for something so fundamental to not be working ... something else is amiss. I tried p, po, and print, to no avail. lldb is useless to me in this state. Hopefully it's some other bit of weirdness that is easily resolved. Will file a bug report in the meantime. Meanwhile, this is encouraging: lldb.llvm.org/status.html – Nonstop

Answer 1

I found one workaround:

Use 'Edit scheme' under the 'Product' menu, select 'Run' in the left bar, the 'Info' tab, and change the Debugger to gdb (this does not apply to xcode 5, which no longer has gdb).

Apparently Apple thought they'd fixed this bug in xcode 4.3.1, but it still happens. I submitted some extra debug information they requested, so I'm hoping it'll be fixed for the next release of xcode. It's still failing in 4.3.2. See https://devforums.apple.com/message/623694 for an update from Apple.

UPDATE

I've tried various cases I was having trouble with, and they all seem to be working fine with lldb in Xcode 4.4.1 - hence I highly recommend upgrading if you're having this problem.

Flabby

Excellent -- thanks! Minor correction: "Edit Scheme" is under the "Product" menu. The rest of the same and it saved my day! – Overhang

Update: Xcode 5 has removed gdb completely and you are stuck with lldb in all of it's glory. – Vanadous

Answer 2

Try with following expression,

p self.view.bounds.size.width

or use,

po self.view

p - Print is only uses to print normal/simple values while, po - Print Object works same as NSLog to print value of an object

Vain

Answer 3

Use Edit scheme under the 'Product' menu, select 'Run' in the left bar, the 'Info' tab, and change the Debugger to gdb.

Product>Edit Scheme>Run(Schemes)>Build Configuration it has three options (Some might see only two 1, 2) 1. Debug 2. Release 3. AdHoc

Just cross check if it is set to Debug if not then make it Debug.

This was the mistake I was doing

Ftc

Answer 4

(Xcode5) This is not really a direct answer to the original question, but I think it may be relevant and I would hate to think anyone else wastes hours as I did tracking it down. The problem I had was that no variable values were being shown in the debug window.

I checked the invocation that was actually being given to the compiler, and found that it was being optimized with -Os despite every project and target in the workspace being explicitly set to -O0, and the settings mentioned in other answers here all being set to Debug. After much searching I found that there is an option in the 'Info' section of each project called "Use xxx for command-line builds" where xxx is Debug/Release or whatever configurations are available. According to the tooltip description, this option should only affect builds done via command-line with the xcodebuild tool (which is a bit strange because that tool is perfectly capable of selecting which scheme to use as a command-line option). Anyway, changing this option to Debug finally got the IDE to tell the compiler I wanted -O0 and -g. I do not recall this ever happening with Xcode4, with the same workspace.

I should also add, that you might want to do a clean before changing this setting. I changed it without cleaning, and suddenly some of my header files were not being found (it seemed that pre-compiled headers were not being generated correctly). After another hour or so of stabbing in the dark, I found that if I first set the above-mentioned option back to Release and did a clean, then I could set it to Debug and build successfully.

Does anybody know if the Xcode development team actually use it themselves? I get the distinct impression that they do not.

Oleoresin

Answer 5

Go to Product->Scheme->New Scheme... and create a new scheme for your target. Clean your product under Product->Clean and your app should run properly.

Doing this solved my problem.

Freightage