When I am having a problem in Xcode, I am told to debug my code with a breakpoint. Stepping through the code, you press that little arrow above the console section to go to the next line. This works fine, like when I place a breakpoint on line 150 in my code, I can then "po" a variable and find it's values.
But when I am trying to step through my code, and go from method to method, a lot of times I will be transported to this weird screen of numbers and letters and things don't make even remote sense in there. See below
Wtf does this mean, and what if anything am I supposed to do with this Klingon transition my Xcode project apparently has intercepted?
Code you write in a language such as Objective-C or Swift is compiled into machine code for execution on a given processor - x86 for the simulator or ARM for an iOS device - In this case I would guess you are running on the simulator.
Machine code instructions perform quite discreet operations. For example c=a+b would translate into something like
fetch a from memory
fetch b from memory
add a and b
store the result into the memory for c
When you single-step through your code in the debugger, it only stops on each line of your program even though many machine code instructions may have have been executed by that step.
What you are seeing is the assembly code for the framework function that has been invoked because you have "stepped into" a function that Xcode doesn't have the source to, so it has to show each low level operation.
You can use the 'step out' button to return to your code and use the 'step' rather than 'step into' button to avoid seeing this.
The line that is highlighted in your debugger is essentially checking the value of the %al register (a register is a small piece of memory in the CPU chip). The next instruction will jump to a different part of the program if the result is that %al is 0.
Look on the left hand side and click on the command before the currently selected code. That will typically show you the last bit of code you wrote before the breakpoint was encountered
In the example below 0 is where the breakpoint was encountered, while 1 is last bit of code that I wrote.
Related
I have recently updated to macOS 13.0 and for that minimum XCode Version required is 14.x series. But my existing project never getting successfully building. Its getting stuck at some point.
Its not getting failed. Build process screenshot is attached below. Its not pointing to any specific class. Seems like there are lots of classes which are getting compiled successfully at last but still build process is stuck at some point:
Seen similar threads like below on apple pages but nothing seems working. Does anyone got resolution?
Xcode 14 project compile error
XCode 14 compile errors immediately disappear or do not appear at all
Something similar has happened to me in the past on a number of occasions. If the Swift compiler is hanging mid-build, usually the issue is that there is some expression that is too complex for Swift to do the type inference on.
What you need to do is first find the exact statement that is causing the hang. This is how I do it:
First find out which source file is causing the problem. Look at the build log to figure this out (the build log can be located by looking at the reports navigator ⌘9 ). Find the build log and click on it. The build log will appear in an editor window.
One of the compiles will still be in progress and its file is the one you want.
The next thing to do is comment out all the code and recompile. This time the compilation will finish (if you have the right file, or there is only one) but probably with a lot of errors. Then you add the code back in, function by function, until one of them causes the compilation to hang again. If it's not obvious which line of the function is causing the problem, comment it out again and then add the lines back one by one until the compilation breaks again.
Once you have located the line, you need to simplify the type inference on that line. If it's a closure, try adding an explicit declaration for its parameters and return type. If it involves some complex array, try adding a type annotation to its declaration. Also try breaking down complex expressions into multiple simpler expressions.
There's no one size fits all answer to this but usually, once you have located the exact line that is causing the problem, it should be reasonably obvious how to fix it.
I'm trying to debug a certain method, but my breakpoints in that method never get hit when I'm debugging on a device, but they do get hit when I am debugging with the iOS simulator. The method is part of a library that my app calls, and I feel like that may be a factor. I developed both the app and the library, and I have both the app and the library open in the same Workspace when I'm debugging.
I put one breakpoint in on the line in my app's code that calls the library method, then a second breakpoint on the first line of the library. When I test with the simulator, both are hit. When I test on a device, only the first one is hit, and the second one gets skipped over (the code for the library method still appears to run).
Is there anything special I need to do to be able to step into a library call when I'm debugging on a device that I don't need to do when debugging on the simulator? Or is it impossible to debug inside a library?
I'm sorry if this is a little unclear - I'm trying to describe what I'm doing as well as I can, but it's pretty strange behavior that I haven't seen before, so it's a little hard to describe. If you need anymore information or anything is unclear, please let me know.
EDIT 1: I noticed something that's a little different, not sure if it's connected or not: I don't have a .h file containing the methods in my library. Actually, there is only 1 method in it (which I'll callmyMethod) that will be called from outside the library (then that method calls the other methods in the library as it needs them). Furthermore, I'm using the TARGET_IPHONE_SIMULATOR pre-processor trigger to make the call in a slightly different manner depending on if it's running on a device or on the simulator. To make the call into the library, on a button click method in my app I just have
#if TARGET_IPHONE_SIMULATOR
extern void myMethod();
myMethod();
#else
extern void myMethod(const char diretory[], int directoryLength);
const char *dir = [[documents path] UTF8String];
myMethod(dir, [[documents path] length]);
#endif
I have matching #if blocks in the method in my library to declare it as needed, and to use dir when it is passed in. This seems to execute just fine. I can tell the code in my library is being called and doing something, it's just not doing what I want it to. Thus the attempts to put in a breakpoint, and the reason for this whole question.
EDIT 2: My library actually contains plain C code, not Objective-C. I put some printf lines into the library code, and its not being displayed. I'm curious if somehow my app is calling a previous version of my library, instead of calling the one that's open in my workspace. That would be consistent with the "it's just not doing what I want it to" part of my last edit. Would it be possible that the device is trying to run an old version of the library it has saved somehow? I thought that completely removing the app from the device before installing the new version of my app would prevent that, but perhaps I'm mistaken?
I'm untangling spaghetti code and as an exercise I'm walking through the application from its launch, breaking on applicationDidFinishLaunching and stepping over and into.
When this first method returns I then break into assembly. Knowing when to step over and when to step into is a real pain. I want the debugger to pause on all the symbolicated code (i.e. code I can see in Xcode – maybe this is called 'user' code? Basically, non framework/library code.), but I don't care about Apple's internal methods.
I'm looking for the practical equivalent of setting a breakpoint on the first line (or every line) of every method and function that I (or my predecessor) has written.
Is there some LLDB voodoo that will do this?
There's a simple way of setting breakpoints on all of your modules' functions, excluding those of any other shared library (Apple frameworks), assuming your product/module is called 'MyApp' that would be:
breakpoint set -s MyApp -r .
However, this will include any library you have statically linked to, which probably means any library you've brought in since dynamic linking isn't allowed in the App Store.
If you tend to prefix your classes, you could narrow down the results by only breaking on functions that are part of classes with that prefix. Assuming your prefix is 'MA' you can do something like:
breakpoint set -s MyApp -r ^[^A-Za-z]*MA
which should cover the majority of your code.
I have been asked to update a old ios application built in Xcode 3.1 with some ios 6 features.
When I tried building the source using my xcode 4.5, it refuses to compile because there are numerous places in the project where simple return statements are used in methods which actually is supposed to return a boolean or similar value.
Xcode 3.1 allows it and 4.5 does not. Somewhere in the middle, apple decided to add this restriction.
My problem is that the code is over 20,000 lines of code and the developers have used the simple return statements where ever they needed the method to stop execution. Since the compiler stops compilation when it encounter's the first of these errors, I have to fix it one at a time and then try compiling it again only to find another error. I tried like 2 hours fixing 100s of such return statements.
Is there a compiler flag or Xcode build setting that would change these errors as warnings and allow me to run this app on Xcode 4.5?
This is the exact error that Xcode throws :
/Users.../Classes/WaterMaps.m:5471:5: Non-void method 'initWithParams:mass:radius:totalAssetInfo:' should return a value
Please help..
This has nothing to do with Xcode, but with the compiler. And not Apple added this restriction, the compilers are not from Apple, they are OpenSource projects (GCC and LLVM/clang).
May I ask why it took you 2 hours to fix 100 such return statements? Fixing 100 such return statements shouldn't take much longer than 5 minutes.
Write return 0; somewhere, select it, copy it to clipboard (CMD+C), delete it again.
Write return; somewhere, select it, hit CMD+E to copy it to search buffer, delete it again.
Go to your source code.
Hit CMD+G which means "find next".
If the found expression is not marked as error, go to (4).
Hit CMD+V (paste), which overwrites return; with return 0;.
Got to (4).
So basically you keep hitting CMD+G to jump through the file and CMD+V whenever you see an error. To quickly jump to the next file, open the error view in Xcode:
Select the first error of the first file and whenever your CMD+G procedure reaches the end of the file, hit CMD+' which jumps to the first issue of the next file on the list. As a developer, you should really learn to use your keyboard more effectively. Keeping your hands on the keyboards makes you hundreds of times more productive than going forth and back between keyboard and mouse/touchpad/trackball/etc.
And how is the amount of code lines ("over 20'000 lines of code") even relevant? It's the amount of return statements that is relevant.
Your code is currently seriously broken and instead of wasting time on thinking how to make this broken code compile, I strongly recommended that you should rather go and fix it. Since once fixed, it will work forever and not break again the next time the compilers are updated and your last hack doesn't work any longer.
I mean how shall a compiler know what you want to return for a method that returns a boolean or an int value if you only type return? The suggested `return 0;' works for all methods that return a numeric value (including floating point) and booleans (0 = false/NO) and makes the compiler happy again. It is the same value that was returned by ancient C compilers in that case.
Note that even in Xcode 3.1 those return statements should have produced warnings all over the place. As a serious developer, always treat all warnings as errors. You project should not have any warnings. Warnings tell you that there is something wrong or at least there might be something wrong and that means you should go out and fix it. Almost all warnings can be silenced by modifying your code. So instead of ignoring warnings or disabling them in the compiler, fix them. Many companies have a zero warning policy today and if your code produces only a single warning, it is rejected. If the author of this code had treated all warnings as errors, you wouldn't have to fix those now.
I am experiencing some strange problems with different iOS projects in Xcode 4.3.2:
The normal behaviour of breakpoint should be like this:
If the program execution reaches the code line with a breakpoint the execution stops and the code line is shown in Xcode. One can then use the "Continue", "Step over" or "Step into" functions go ahead with the execution. Using "Step over" or "Step into" will show the code line which will be executed next.
The first part (stopping the execution when reaching a breapoint) works without any problem. But Xcode does not show the corresponding code line. After the execution stopped I can use the Step functions but again Xcode will not show the code line. This way the breakpoints are pretty useless since I cannot see where the execution stopped.
The problem does not always show up. Sometimes it works and then in suddenly stops working. One time a break point works and during the next execution it does not work.
Most of the time stopping the execution and running the app again solves the problem. But it is just a matter of time till it stops working again. Sometimes only restarting Xcode has any effect.
BTW: The debugger is set to GDB since LLDB has other problems.
I found some other posts dealing with breakpoint problems. But in all cases the problem was different to one I am experiencing (execution did not stop at all, breakpoint where disabled automatically, etc.).
Does anyone know this problem or has an idea how to solve it?
Andrei