The attached screen shot says it all: I have a valid true Bool, I negate it with the bang operator, and (Xcode tells me) I have an invalid value.
It appears that this "invalid" value does behave as if it were false. But really, wtf?
I've had this issue in Xcode 8.3.1 and Swift 3.1 https://github.com/onmyway133/notes/issues/278
I tried
Clean build folder and delete derived data folder
Delete the app
Reset simulator
Restart Xcode
Restart Mac
But does not work. The workaround is to
let enabled = disable ? false : true
I'm no LLVM expert but I wouldn't be surprised about this behavior at all, unless optimization is set to Onone in which case it should have left your code alone. The intermediate variable is just asking to be optimized away, after all.
Got the same issue, with correct value for add code like print(theBoolValue).
But when use p in swift command line. Or just check the value in debug stack, the value become <invalid>(Oxfe).
Related
I am trying to add a Symbolic Breakpoint in XCode to check for UI engine modifications on the background thread.
What I am doing is the following:
However, the error message I am getting back is always:
Stopped due to an error evaluating condition of breakpoint 5.1: "!Thread.isMainThread"
Couldn't parse conditional expression:
error: use of undeclared identifier 'Thread'
UI Engine must be modified on main thread.
I do not understand why the breakpoint condition cannot evaluate my condition. Can someone explain what I may be doing wrong here? I have tried putting that in Obj-c as well, to no luck.
EDIT: Obj-C version, here: !(BOOL)[NSThread isMainThread]
EDIT 2: Xcode version Version 11.3 (11C29)
EDIT 3: Ok, so, closing XCode and reopening has gotten the Obj-C version "working" they pause on a breakpoint for something like, 4-5 minutes each time. This effectively makes these breakpoints unusable. Not sure how to resolve this.
I was able to get your original symbolic breakpoint working as expected by writing the condition as
(BOOL)[NSThread isMainThread] == NO
I suspect there's a better way, and comparing a BOOL directly to NO is very bad style, but at least it got me past the "doesn't work" stage to the "does work" stage.
To clarify, setting symbolic breakpoints and using conditions DOES work, but
I would hazard that self and Thread are not available as symbols for much of the UIKit framework because there is no debugging information available for most of it, hence the error: use of undeclared identifier 'Thread'.
See the answer in this post:
How to log out self when add a symbol breakpoint at -[UIViewController viewWillAppear] method
There is also additional info about creating symbolic breakpoints for child classes and a possible workaround using an objective-c condition here:
Using of symbolic breakpoints for child classes in Xcode?
That being said, if you are only interested in particular classes in your modules where that method (layoutSubviews) is invoked, you can specify the module inside your symbolic breakpoint, and if you have your own implementation of that method (e.g. you have overridden it in your class code), the condition Thread.isMainThread or !Thread.isMainThread will in fact work for that class.
I know this may not in fact solve your dilemma, especially if you need to check all the invocations of layoutSubviews, but I hope it at least helps to explain why a condition using Thread does not work all the time.
When I use the terminal/console to print out a value by typing po object it prints blank for all objects. This only happens for my work project which is really big and my small demo projects work fine.
Also its not happening for any of my colleagues. I was using Xcode 10.2 and upgraded to Xcode 10.3 to see if it fixes the problem.
stringValue is an extension on bool that returns "true" or "false" however this happens for all objects so I don't think the code there is relevant.
Due to the huge compile time of our app its quite time consuming to always write print(object) or debugPrint(object) in the code.
Any ideas how to fix the issue?
Can you try to press on i it does the same, but sometimes it's work for me.
Also check this out: XCode's po command has stopped working
Let me know if this help you.
Try the v command.
From the XCode release notes
The LLDB debugger has a new command alias, v, for the “frame variable”
command to print variables in the current stack frame. Because it
bypasses the expression evaluator, v can be a lot faster and should be
preferred over p or po. (40066460)
I'm using Appcode-EAP 3.2, but I've also tried this with Appcode 3.1.7.
When stopped in the debugger, I can see the local variables,
e.g.
fromJSON = []
self = []
However, if I move one of these to the Watches window to examine its contents, I get this:
self = Cannot evaluate expression for language Swift
I can't believe it isn't possible to see the values of a variable or property. Can anyone guide me as to what I'm failing to do?
Current AppCode versions (stable 3.1 and 3.2 EAP) don't support Swift debugging. It should be included into the final 3.2 release however: https://youtrack.jetbrains.com/issue/OC-11626
I come from a Delphi and .Net background and have just started iPhone development. I just came across a problem whilst debugging.
I had the following code:
if ([displayText rangeOfString:#"."].location != NSNotFound) .....etc
I wanted to evaluate this whilst I was debugging but could not work out how to do it. I found the Expressions window and entered the below but nothing happened:
[displayText rangeOfString:#"."].location
As I'm used to Delphi & .Net (and I know XCode is a different product) its very easy to stick in variables, methods etc into a watch window and then see the result but I cannot see how to do this in XCode. Please can you tell me how I evaluate things whilst debugging??
Thanks
In your case, what you would do is at the debugger is type:
p (NSRange)[displayText rangeOfString:#"."]
You can print out the value of objects with po, but things like C structures have to be printed out with "p" and you have to cast the return types from ObjC calls to the correct struct type.
Also, just putting this in the Expressions window should result in a value:
(NSRange)[displayText rangeOfString:#"."]
In both cases you will see the whole NSRange struct, with location and length.
You can watch variables by going in the debugging drop down in the main menu on top and selecting watch variable. You can also right click and you should see the option "watch variable." Alternatively you can hover your mouse over the desired variable while stepping through your code to see its value at that time
I am having a weird error message when i try to build my application for device:
{standard input}:3884:invalid offset, value too big (0x00000408)
Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 failed with exit code 1
the class that issued this error message contains a function that has a huge switch statement with contains other switch statements in its cases. It is almost 1200 lines long!!
When i commented this function out the compilations was complete. So i predict this is whats meant by " value too big" in the error message above, correct me if am wrong.
Now how do i get over this limitation? I am thinking of a way to break my function into different parts and implement them in categories of the class in different files. But am not sure it is gonna be that easy as the function only contains switch statements within a huge statement. I will look at this further but does any one else have any other suggestion?
Cheers
AF
Firstly, if you're using xcodebuild directly try building via the IDE as some reports seem to suggest this can help, unlikely though that may sound.
Secondly, if this is a compiler bug (it sounds like it is and there are quite a few similar reports on the hyperinternetweb), you could also try switching to using LLVM (via your projects "Compiler version" settings) and see if that makes a difference.
Finally, you could simply avoid the issue by using an if/else construct instead, painful though that will be.
UPDATE
To try out LLVM (instead of gcc), select your project's build target from the "Targets" section in the Groups & Files area, alt-click and select "Get info". In the window that appears then select the Build tab (if it's not already selected) and scroll down to the "C/C++ Compiler Version" setting within the Compiler Version category. You then then choose to use "LLVM compiler" instead of gcc.