it may be obvious with the new Xcode Debugger, but, i couldn't see the actual value:
int i=0; //i put a breakpoint on this line
i=1;
i=2;
When the app stopped on the first line, i put the mouse cursor on the i and something should refer me the correct value, means 0, but this was not the case. I also try to print the value on the console:
print i
But i got this:
(int) $1 = <unsufficient data for value (only 0 of 4 bytes available)>
Although i am sure po is not for primitives, i tried it too:
po i
Nothing from the above ways has worked to me.
i just had the same problem. this fixed it for me:
go to "edit scheme", then "Run", then "Info", then "build Configuration" and select "Debug" instead of "Release".
#Apple: BTW it should be called "insufficient" :-)
Related
I have the following Raku code:
class Thing {
method close {
say "closed";
}
};
for 1..1000 {
my $x will leave { .close } = Thing.new;
}
Running it, I get the error:
Lexical with name '$x' does not exist in this frame
in block <unit> at c.raku line 7
Interestingly, this only happens if the number of iterations is high enough (with 500 or 100, I do not get any error messages).
If I change the body of the cycle to
my $x = Thing.new;
LEAVE $x.close;
then everything works without errors as well.
What is happening here? Did I misunderstand the will leave construct? (It seems to me the two versions should be equivalent.)
EDIT: Further observation – when running the code multiple times, the error appears nondeterministically. This suggests that the problem is somehow connected to garbage collection, but I am still confused as to what actually happens here.
I am using Rakudo v2021.03.
This is a bug. Have made an issue for it: https://github.com/rakudo/rakudo/issues/4403
I suggest using the workaround in the meantime.
I know how to set a symbolic breakpoint. I was wondering how can I make one myself? I will have a function, and if something is not asserted, I don't want an assertion failure, but a log message saying something like "Number is negative, break on XXX to debug" just like layout constraint satisfaction problems. When user adds symbolic breakpoint at XXX, I want to break when assertion fails. How do I construct that "XXX"?
Make a function or method with a fairly unique name (to prevent name collisions) which is where the error you mentioned is logged. Then that will be the symbol to set the breakpoint on.
- (void)myAPI_Range_Error {
NSLog( #"%#", #"Number is negative, break on myAPI_Range_Error to debug" );
}
- (void)myAPI_SomeMethod {
if (self.startNumber < 0 )
[self myAPI_Range_Error];
}
Learning how to code on Mac OS X for me is mainly about familiarizing myself with Xcode and I have this weird problem:
when I debug code and I move the debugger arrowhead from one line to another, I always get EXC_BAD_ACCESS. Consider the following example:
int main (int argc, char** argv)
{
printf("Test1\n");
printf("Test2\n");
printf("Test3\n");
}
I start stepping over line by line and I can see the output strings being displayed in the Output window. When the code reaches third printf() statement, I take the green arrowhead and drag it back to the first printf() statement. What I woud expect is that the execution would resume on this line, but after stepping over, I get EXC_BAD_ACCESS in __vfprintf:
EXC_BAD_ACCESS(code = 1, address = 0x6)
I have tried several similar dummy examples with the same result. I feel like missing something too obvious to notice it.
Regards,
Ondrej
When I use NSLog, I get output similar to the following:
2012-01-24 17:05:32:860 App[21856:71939] {logging goes here}
I recognize that '2012-01-24 17:05:32:860' is the date, 'App' is the app name, but I have no clue what '[21856:71939]' means. Can someone fill me in on what that is and where it's generated at?
All I'm trying to do is get logging that lines up nicely so it's easy to read, but the '[21856:71939]' varies in digits enough to mess up any alignment attempts. If I knew how the numbers in '[21856:71939]' were generated, I could add spaces as needed to make it line up correctly, but that's my only idea at this point.
Any help would be much appreciated :)
21856 is the process id. 71939 is the thread id.
You can generate this portion of the log on your own using:
[NSString stringWithFormat:#"[%ld,%lx]",
(long) getpid(),
(long) pthread_mach_thread_np(pthread_self())];
Edit 2014-09-23:
At least on the simulator in iOS 8, the second number is now the pthread_threadid_np of the thread.
__uint64_t threadId;
if (pthread_threadid_np(0, &threadId)) {
threadId = pthread_mach_thread_np(pthread_self());
}
[NSString stringWithFormat:#"[%ld,%llu]", (long) getpid(), threadId]
IIRC, the 21856 is the process PID, and the 71939 is some sort of thread identifier.
It's a thread ID, but I don't actually know how they are generated.
you can grab it yourself using this
pthread_mach_thread_np(pthread_self())
but that doesn't answer how you would set it up with correct lining. On the other note, when you're debugging, go to the last tab (Show the log Navigator), double click on Debug App, it'll show up nicely
I was wondering if there is an effective way to debug problems in xcode while coding in Objective-C. I create webpages constantly and code in jquery and javascript where you can set various alert boxes in different places in your code to determine if your script is properly executing sections. Can you do something like that in xcode to make sure that your script is executing methods properly and creating variables properly?
Thanks
Use the debugger - that's what it is there for! Set breakpoints by clicking in the grey are next to the line of code you want to break on. When this line of code is going to be excuted, the debugger will kick in and highlight the current place in execution. You can hover the cursor over variables in the IDE to examine their values, view the current call-stack (to see here this code has been called from) and get a list of local variables to help track program state. You can modify variable properties here too which often makes debugging simpler.
Execute code line by line by 'Stepping Over' (cmd+shift+o), which executes the current line, 'Stepping Into' (cmd_shift+i) which steps into the current line of code (if it is a function), or 'Stepping Out' to return back up the call stack.
If you want to stick to 'old-school' printf style debugging, go with NSLoging output to console.
NSLog(#"this text appears");
prints the following to the console:
this text appears
To print some basic variable values:
CGFloat pi = 3.14;
NSString *aFloatString = [NSString stringWithFormat:#"%.2f", pi];
NSLog(#"pi is equal to: %#", aFloatString);
Prints:
pi is equa to: 3.14
Standard c formatters can be used in NSLog i.e %d for int, %.2f for a float to 2 decimal places etc. Use %# for NSString*s.
Remember that NSLog will remain in production code unless you #IFDEF it out of release builds (or something similar), so if you don't want a performance hit, or embarrassing console logs to accompany the app you will want to remove them.
I've been known to litter functions that dump the following to console - and it isn't good:
OUTPUT:
Number of vertices is: 1200
<Requested reduction>
Can I kick it?
....
....
YES. I. CAN!
Number of vertices is: 800
Could have done with removing things like that :|
yes, the debugger can do all the things you want to do (just set some breakpoints - right click where you want them - then build&debug)
You can try writing to the console.
NSLog(#"Some status message here");
NSLog(#"The value of myObject is:%#", myObject);
To view the output of your application, while running with Xcode, click Run->Console and you will see all of the output from your application.