Expression in Xcode 4.3.2 Debug area not evaluated - objective-c

I'm doing something wrong. I have added an expression, I can see the expression with the "E" symbol in the Debug area, but the expression is not being evaluated, its value is not displayed there (it is in scope at that time).
When I use the debugger (lldb) directly, it works well.
Xcode 4.3.2.
What should I do?
Thanks

You are trying to evaluate a boolean and print it as an object.
You want to use print [self isEditing] or print (BOOL)[self isEditing], depending upon whether the debugger complains that it doesn't know the type of the member or not.
The po command prints an object description, not an arbitrary value, and should only be used when the result of the expression on the right is an object, such as po self.
The same problem occurs in the expression editor. If you use the expression [self isEditing], the debugger won't understand it. However, if you use (BOOL)[self isEditing], it will display correctly.

try adding the expression as self.isEditing, without the square brackets. Works here

Related

What's the point of "val variable =" following by nothing in Kotlin?

I accidentally hit enter after a value assignment and to my surprise it compiled perfectly fine!
What's the point of having this syntax? I tried to search for it online but only found articles about the Nothing-type, but nowhere close to this surprising syntax.
Technically, return 123 is an expression which returns Nothing. Just like throw RuntimeException(). You can save the result of this expression in your variable but I cannot imagine how you can use it :)

Cannot find the execution point at debug evaluation expression

I want log something when breakpoint is hit in AppCode. But there is no documentation for how to write a right evaluation expression for the evaluate and log section on debug configuration window.
if i write
NSlog(#"some message")//error
the console log:
error evaluating NSLog(#"some message");: Cannot find the execution point
I have no idea how to write correctly!
There is a feature in AppCode called "Evaluate expression" (⌥F8). You can call it during the Debug and evaluate particular code expression without p/po and LLDB console. You can normally write the code in the window, press "Enter" and see the result of this particular expression.
This field uses this feature to evaluate some particular code at breakpoint, and evaluation result of NSLog is void. Here you can right for example something like self.view.frame.size.width <= 100 and have result printed to console. If you want just print some message to console - select only Log message to console and AppCode will print something like
Breakpoint reached: ViewController.m:6

What's the difference between "p" and "po" in Xcode's LLDB debugger?

Example: I write the following string in my old project and a new, clear one:
UIInterfaceOrientation k = [UIApplication sharedApplication].statusBarOrientation;
Console input/output for a clear project:
(lldb) po k
UIInterfaceOrientationLandscapeLeft
And something awful in my old project if I write "po k" - a list of useless integers.
Additionally, I can't print most of the objects in the new project.
I don't know what is going on in your case, but just so folks are clear on the difference between po & p:
The p command (a.k.a. expr --) takes the arguments it is given, compiles them as though they were a source code expression written in the context of the current frame, executes the result - either by running an interpreter on the result of the compilation if that is possible, or by JITing the result of the compilation, inserting it into the target program, and running it there. Then it prints the result of the evaluation.
The po command (a.k.a. expr --O --) does everything that p does, but instead of printing the result, if the result is a pointer to an ObjC object, it calls that object's "description" method, and prints the string returned by that method(*). Similarly, if the result is a CF object, it will call CFShow and print the result of that. If both these attempts fail, it will go ahead and print the result as p would have.
So po is mostly like p. But you can get some weird results if you use po on things that it aren't actually objects. For instance, ObjC has a optimization (tagged pointers) that represent the contents of some objects (e.g. NSNumbers) in the object pointer. There isn't a "real" object, just a cooked pointer. So if you try to po an integer that just happens to look like a tagged pointer, you'll get the description of some probably unrelated ObjC object, not the value of the integer.
And of course, po is doing a lot more work, so unless you really want some object's description of itself, p is more efficient.
Actually, it calls debugDescription, if that exists, and falls back to description if it doesn't...
p = print
po = print object
p prints value of primitive variable or value of a reference
po try to call -description for that object and print returned string
Use po, p, & v to print variables
po ends up compiling & executing twice, once to evaluate your expression and again to get the object description.
v doesn’t compile at all: can’t evaluate any expression but does allow property accessing and does recursive dynamic type resolution so each property is treated as the actual runtime type.
For people who are interested in learning more : https://developer.apple.com/videos/play/wwdc2019/429/
Add this as an answer for visibility, Also explains the functionality of each debugging commmand
po tries to treat what you want to print, as an object. In many cases it is similar to p, but there are cases where the difference emerges.
The simplest way to see the difference: compare the output of p 0 and po 0.
(lldb) p 0
(int) $26 = 0
(lldb) po 0
<nil>
UIInterfaceOrientation is no (Objective-C) object, but an integer (enum:NSInteger). You should not use po (print object) at all.
It seems the difference is lldb/gdb debugger. The only way for iOS project to make debugger more workable is expr #import UIKit. But it may not work for older xcode versions and... you need to input this string in the console after each relaunch. The only way to automate it is an extra breakpoint with this expression.
p prints value of primitive variable or value of a reference
po try to call -description for that object and print returned string
There is also **v command** in lldb. Explaining using example.
protocol Activity {}
struct Trip: Activity {
var name: String
var destinations: [String]
}
let cruise: Activity = Trip(...)
Using v command
(lldb) v cruise.name
(string) cruise.name = "print name"
//As it uses dynamic resolution
Using p command
(lldb) p cruise.name
//execution interrupted
Strip debug symbols during copy
In most answers they advice to set optimization to "none" but forget that this option should be set to NO (at least for debug configuration).
This is in reference to what Jim Ingham said. Type "p " instead of "po ". When I do that Xcode displays the correct information. Try that.

How to print chained variables using GDB console?

How to print C type variables at GDB console in xcode4? I'm able to print variables using p var, also able to print variables like p myObj.property but unable to print variables that that are on 3rd level depth. For example using p objName.pointerToOtherObject.someProperty does not work. The GDB dislays "There is no member named someProperty." message but it is there for surely. I'm using the 4.02 version of xcode4 but still it sucks when it comes to displaying properties, variables and etc from debug area. I mean it is unable to show the content or arrays and dictionaries, also, sometimes, it is not displaying the values of vars when I move the mouse over that var, in that case I need to click and move the mouse somewhere else and then move the mouse over again, then it works. Maybe I'm missing some hints but those small problems sometimes annoys me :) For object printing I' using po.
The solution would be to use method messaging syntax instead of property syntax:
p [[SomeObj pointerToOtherObject] someProperty]

Obj-C keeping memory addresses the same on next debug

I'm not sure if there is a name for this technique, but I remember doing something like this a long time ago in C++. I would like to breakpoint and observe a specific object of which there are hundreds in my program. It would be nice if you can tell the compiler to use a reserved space of memory so that I can run once, pull out a memory address, then run again with the guaruntee of having the objects allocated to the same address in memory so that I can see what happens to this specific object the next time around.
At the moment I am just assigning a 'debug id' which gets incremented with each allocation but thought there might be a cleaner way of doing it. I'm sure I've done this before with Vis Studio / C++...
You can set a conditional breakpoint in Xcode so that it will only break into the debugger if a certain condition is satisfied.
To do this, set the breakpoint normally and then right-click on it and select Edit Breakpoint.
Locate the breakpoint in the Breakpoints window and double click the "Condition" column. You can then enter an expression, something like:
(BOOL)[[yourObject name] isEqualToString:#"foo"]
This will break only when the name property of yourObject is foo.
Note that you need to cast the result of the expression to a boolean, otherwise gdb doesn't know how to deal with the result of the expression. You also can't use dot notation syntax, you must use the full square bracket syntax.