My app freezes in Release configuration only.
I tracked down the issue to this setting:
It is no secret that the Swift compiler is buggy.
I have never seen a compiler crash (and crash often).
So, is it "safe" to submit to the App Store with Optimisation Level set to "None"?
Any experience?
Apple does not recommend shipping your application with no compiler optimizations.[1]
None: The compiler does not attempt to optimize code. Use this option
during development when you are focused on solving logic errors and
need a fast compile time. Do not use this option for shipping your
executable.
Taken from apple.developer.com.
While compiler optimization bugs exist,[2] Xcode is probably not the source of the problem, as explained in the answer provided here by the stackoverflow user #kfmfe04:
In some extremely rare cases, the debug code works, but the release
code fails. When this happens, almost always, the problem is in my
code; aggressive optimization in release builds can reveal bugs caused
by mis-understood lifetimes of temporaries, etc...
Remember that you can always track down the source of the problem by examining the compiled assembly file, but it will require some ASM knowledge to understand what the compiler is doing under the hood.
In Xcode options:
Debug -> Debug Workflow -> Always Show Disassembly
Then you put a breakpoint where you want to check the ASM code.
Related
I have a class that takes 3 seconds to process data in Debug mode, but only takes 100ms in Release mode. There is obviously something wrong with it but all tests pass so I don't need any Debug features when using it.
Is there a way to make Xcode run the project in Debug mode but do all Release optimization for this single class?
The only workaround I can think of is to turn this into a framework with a release compile flag but that seems like a bit overkill.
The only workaround I can think of is to turn this into a framework with a release compile flag but that seems like a bit overkill.
This is the only stable way to do this at the moment (with Xcode 13). One more option is that you can try doing some timing measurements, it might be possible to rearrange your code so that even the debug codegen gives better results.
If this is throwaway code, you can try marking individual functions with the underscored attribute #_optimize(speed).
I'll repeat the disclaimer at the top of the doc:
WARNING: This information is provided primarily for compiler and standard library developers. Usage of these attributes outside of the Swift monorepo is STRONGLY DISCOURAGED.
Some time ago (a year?) we ran into problems with debug builds that had whole module optimization enabled. When tracing, the debugger would jump to unexpected addresses. Since then, we've been shy about enabling this on our debug builds. We do enable it for our release builds.
Is anyone aware of any existing --- even subtle --- issues with debugging an executable that has been optimized this way?
Or, conversely, has everything been working fine for you with this configuration?
From what I understand it should not cause issues as whole module optimisation mainly means that Swift knows what it can directly address ( a straight up _call ) compared to a VTable lookup as well as reduce the costly retain release cycles.
Similar to this, it is a good idea in general to use access control in swift right when you writing your code. privatizie everything unless you really need to access it outside. Use final on classes that don't need subclassing etc.
Usually when you enter the assembly view in Xcode is because of symbols missing for the debugger on libraries being called.
A small tip for debugging: I recently found a bug in my own code when implementing a TLS socket by simply looking up the address and the referenced method, downloading the source and looking up what was missing or causing the issue.
Now that said, in general it will greatly increase debug build times so do you have any reasons for running -whmo in debug?
When ever I try to push my app to my ipad or ipod to test them I get this error...
alignment lost in merging tentative definition _resultbuffer.
What is it? Any idea how to fix it?
I'm going to take a wild guess here, apologies if I'm too far off the mark:
On the ARM processor alignment can be an issue, particularly if you're accessing a variables in an unaligned manner, I suspect this is what you're seeing:
Here's a couple links that might see you through this:
gcc type-attributes documentation (Yes, I know its compiling with clang, this still may help)
Basically the same thing from ARM's documentation
A pretty good write-up about ARM alignment and how to avoid problems
Most flavors of ARM will automatically 'fix' this by adjusting the alignment on the fly, however this is configurable. The down-side is it causes a CPU interrupt to handle it, so if you're doing this over and over it'll slow things down. I haven't run into this on iOS, so I can't say for sure what the behavior would be. Odds are its best just to fix it.
I've looked at Microsoft's MSDN and all around the web, but I still haven't been able to get a really good idea of what it is.
Does it mean the completed program loads DLLs at different times during its execution, as apposed to all at once upon launch?
Am I totally way off? :)
Linking involves packaging together all of the .obj files built from your source files, as well as any .lib files you reference, into your output (eg .exe or .dll).
Without incremental linking, this has to be done from scratch each time.
Incremental linking links your exe/dll in a way which makes it easier for the linker to update the existing exe/dll when you make a small change and re-compile.
So, incremental linking just makes it faster to compile and link your project.
The only runtime effect it might have is that it may make your exe/dll slightly bigger and slower, as decribed here:
http://msdn.microsoft.com/en-us/library/4khtbfyf.aspx
Edit: As mentioned by Logan, incremental linking is also incompatible with link time code generation - therefore losing a possible performance optimization.
You may want to use incremental linking for debug builds to speed development, but disable it for release builds to improve runtime performance.
Delay loaded DLLs may be what you are thinking of:
http://msdn.microsoft.com/en-us/library/151kt790.aspx
Also, quite importantly, incremental link is a prerequisite for Edit&Continue - possibily to edit your code and recompile it on the fly, without restarting.
So it is a good thing to have on debug builds, but not release builds.
Within several projects, I am using 3rd party code that produce more than a few compiler warnings. I obviously do not want to go through and modify code of actively updated 3rd party projects.
This leaves me with a lot of unnecessary warnings that drown out warnings in MY code.
I have used some compiler flags to suppress specific warnings on a per file basis, but that is much too tedious for open source code with 10-20 .m files.
Is there a way all warnings by Xcode group or file path? Or does somebody have a better suggestion?
(FYI: I am using the LLVM 1.5 compiler)
In my experience, XCode 3.x seems to only show the warnings for files that have actually been compiled in the most recent build, so if you build the project, modify a single file and then build the project again, you'll only see the warnings for the modified file. I generally find this to do more harm than good (especially since in Objective-C it's only a warning to call a selector that doesn't exist!) — and thankfully it's fixed in XCode 4 — but in your case in might be useful.
However, for various reasons you might want to consider putting the third-party code into a Framework. This wouldn't automatically suppress the warnings (although it might make it easier to suppress them) but it would mean that the third-party code was compiled into a library and therefore wasn't part of your normal compile cycle.
Turning off warnings on a per file basis is super simple. All that is required is a compiler flag. Here’s the step by step process.
Open the Project Navigator in Xcode
Click on the Project icon at the very top of the navigator
In the resulting detail pane select the target that you are working
with
Select “Build Phases”
Expand “Compile Sources”
In the list locate the file that you’re interested in
Double click the column under the “Compiler Flags” column next to
your file
Add a -w to the resulting dialog
Click “Done”
Build your now warnings free project
here is the reference link
http://blog.bluelightninglabs.com/2011/12/suppressing-xcode-warnings-on-a-per-file-basis/
This is certainly not the easier solution, but you could go through these third-party libraries and fix their warning-causing bugs and submit patches. Then, the warnings go away, the bugs are fixed, and everybody gets to enjoy both improvements.
(How many warnings you'll be able to squash this way will depend on what they are: Deprecated-API warnings may be unavoidable if the library needs to support an older version of Mac OS X or iOS where the now-deprecated APIs were the only way.)