I have a program which runs fine on the device in Debug configuration, but fails as a Release. Anyone have this experience, and how do I fix it?
Thx
I ran into the same problem - App worked fine on simulator and device in Debug mode, but neither in Release mode (it would install, but just display the splashscreen)
Xcode 4.3.2
iOS Deployment Target 4.3
I kept seeing answers on StackOverflow that said this was a memory management issue, but that didn't make any sense to me since the debug version worked perfectly fine when loaded to my iPhone 4S. I also checked Build Settings to see what differed between the two modes, and I skipped over the one difference that mattered in the end - compiler optimization.
In Build Settings -> under Apple LLVM compiler 3.1 code generation -> Optimization Level, change the Release setting from the default Fastest, Smallest [-Os] to None[-O0] . Fixed my issue.
Found that solution in this blog post: http://www.mindjuice.net/2011/11/30/how-to-fix-an-app-that-crashes-in-release-but-not-debug/.
The Apple Documentation helps, but doesn't explain why doing just the opposite fixes things:
Code optimizations of any kind result in slower build times because of the extra work involved in the optimization process. If your code is changing, as it does during the development cycle, you do not want optimizations enabled. As you near the end of your development cycle, though, the release build configuration can give you an indication of the size of your finished product, so the Fastest, Smallest option is appropriate.
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.
Fastest, Smallest: The compiler performs all optimizations that do not typically increase code size. This is the preferred option for shipping code because it gives your executable a smaller memory footprint.
Post
Some
Clues!
What do you mean by "fail"? Crash? Hang? Jettisoned for memory use? What are the symptoms of the failure? Got backtrace? Do you have anything in your code that behaves different in debug vs. release? Any #ifdef DEBUG type shenanigans? asserts with side effects? Did you mess with the compiler settings? Got C++? Assembly?
I see a hint of a clue in the comments; illegal access of a variable. Most likely, this is caused by the optimizer re-using a stack slot more quickly in release than debug. Which, generally, boils down to an over-release issue.
Even when building for release, you can still turn on zombie detection.
Also, have you done a build and analyze and fixed any problems it indicates?
Related
I am using Unity as a library for SwiftUI quite a while now. However when updating to the newest iOS version (16.1) it stopped working. Compiling runs without a problem but during runtime I get an error when Unity is starting:
in:
I even started a completely new project with Unity included to SwiftUI and get the same error. As this is some kind of assembler code and I certainly do not know how to read it I don't really know where I have to start searching.
In the console I get: "warning: UnityFramework was compiled with optimization - stepping may behave oddly; variables may not be available." I tried several ways to turn off optimization as described in related questions which did not work. When unchecking "Debug" in the scheme options the project starts normally
A similar thing happened to me. I'm not entirely sure if it's the same problem but in the console, I got a message saying UnityFramework is running optimized and may behave oddly. Unfortunately, I've tried a couple of ways to disable optimization but I've yet to find a solution.
For now, I'm able to bypass this error by disabling the debugger entirely. In order to do this, you have to go to Product -> Scheme -> Edit Scheme and uncheck debug executable.
I'm not sure if this will work for you but I figured it'd be worth a shot!
I have an issue where when I run my application in debug mode, the application shows obvious runtime lags. As specified in numerous articles, the application bundle will run up to 10X faster than when running from xcode (including with instruments).
However, when I open the app (going through the project explorer/products/app_name.app) and show in finder then run the app, several features that work perfectly in debug mode (in my case, certain keyboard press functions).
The app runs much faster as expected than the debug mode runtime, but lacks some of the behaviors which work in debug mode. Furthermore, some other actions close the application altogether.
I don't know where to start figuring this out but have some intuition and would like confirmation what it might be:
1-Instruments: is there a difference of memory usage between debug and application bundle for which debug keeps a cap on memory usage, CPU usage etc?
2- COnsidering cache misses, is it possible that my nSResponder when I activate a key does not catch some later down the track switch cases, which will create a cache miss? (I doubt this since my controls file runs as an extension to one of my main loops). Note: If this works fine in debug mode, why would it not work in the application itself?
Any pointer to why this behavior greatly appreciated, so that I don't make large changes that won't affect the outcome (It's a large project).
So are you saying that when you compile for debugging (-ONone), then things work. But when you compile for release then some things don't work?
Try unchecking 'Enable backtrace recording' in the Options tab of the Run scheme action.
My app runs really slow with Xcode 4.5, and i just realized it's due the debugger always on.
It seems you can't select NONE under Manage Schema/Release/Debugger, so how can you disable debugger on Xcode 4.5?
many thanks in advance
It is unlikely that the slowness is due to the debugger being attached. It is more likely that the slowness is due to compiling in Debug rather than Release mode. Debug does not optimize the code. Release does. You can switch your configuration to Release and it should speed up, but be more difficult to debug. You can create separate Debug and Release schemes if you like.
Note that the specific difference in Debug and Release that matters here is the compiler optimization. Debug passes "-O0". Release passes "-Os". You could of course create a Debug configuration that passes "-Os" without changing other things (like turning off assertions, if your Release configuration does that).
Ok
SO recently I've being having a lot of trouble with an application working in debug mode but not working in distribution mode.
Is it possible to use xcode debugging tools such as break points and variable tracing with an adhoc distribution build of an app?
If it's not how would one usually go about debugging such a thing?
Assuming that your crash logs aren't giving you any clues (you'll need to hook up to the device to get them) there are lots of things you can do.
But I'd start by looking at the crash logs ... the clues will be there and don't forget Apple make distribution crash logs available to you through iTunesConnect.
1) Copious logging is one thing. Lots of developers use a switch so that in debug, logs go to the console but for other builds they are dropped. Consider a different option where you log to a file instead. You could then push the log files to a remote server for debugging. It's a bit of a slog to set this all up, but once you've done it, you'll wonder how you ever lived without it.
2) Another option is to use Flurry and log events when you detect that things have gone wrong. This can cover more controlled problems when things aren't as expected rather than random crashes. This can be a useful feature for released apps provided your terms and conditions are clear about what data you are logging and why.
3) Make sure you do a clean build, I'm sure you've already done this, but sometimes it clears these issues.
4) Are you using external libraries / modules? I've come across issues with older versions of TT where the arm6/7 build settings were wrong and this was causing issues for distribution builds. Basically check through the build settings for each profile and make sure it is what you expect.
5) Suspect a race condition. In distribution mode (often because the logging is turned off) you will find that your application runs a little bit faster. That can reveal timing issue bugs in badly written code.
So yes ... there is a lot you can do ... you just can't attach the debugger ;-)
Not possible to debug an application in distribution mode.
The build configuration difference between Distribution, Debug, and Release is really whatever parameters you have set for that in XCode. If your Distribution config is giving you problems and the release isn't, the easiest way to fix it is to go back through Apple's steps on copying the Release config and making the changes to make it a Distribution config, like you did originally.
The alternative is to go through every line of the configurations for Release and Distribution and find what's different. The other way is a LOT faster. :)
I've heard it might be a good idea to turn off "compile for thumb" in an iPhone target's settings to increase performance. I'm having some trouble finding this setting though. Since I couldn't find it in my current project, I decided to make a new one (where I could find and set it), and copy my files over to it (and also update all libs I'm using at the same time).
But now it seems like this setting has disapperad from this new project also. No matter what SDK I choose, simulator or device, the setting will not show up in the target settings! I do seem however to still have a variable called GCC_THUMB_SUPPORT under the category "User-defined" all of the sudden. What is this?
I tried making a new target, but the setting will not show up in that either (not even GCC_THUMB_SUPPORT).
GCC_THUMB_SUPPORT is the right variable. Just set it to NO to disable THUMB code generation.
A general rule of THUMB is, to disable it if your code is floating point heavy :)
More about that here.
Update:
The advice to compile for the THUMB instruction set is no longer valid (actually since the iPhone 3GS).
I've found that the compiler settings ("GCC 4.2 - Code Generation", "GCC 4.2 - Language", etc) only show up in the Target info build settings window when the Active SDK is set to Device -- and the "User-defined" category only shows up when the Active SDK is Simulator.
And yes, disabling Thumb compilation can be a big help to performance if you're dealing with lots of floating point math (e.g. floating-point audio processing). Though it's not, of course, an all-purpose magical speed-up (and supposedly Thumb-compiled code can run faster in some situations), so you'll probably only find disabling Thumb useful if your code has that kind of bottleneck.
"Compile for Thumb" should be under Target/Get Info/GCC 4.2 - Code Generation. If it's not there (I'd be surprised if it's not), set the user-defined variable.
Keep in mind that this improves performance only under a narrow set of circumstances that you should understand before fiddling with it.
The standard instruction set for ARM is 4-bytes. Using "Compile for Thumb", the compiler is able to use 2-byte instructions. This results in a much smaller library, but also a slower one (somewhat debatable). More critically, there are issues with running under ARMv6. In our case, we could not generate stable output from Monotouch (fix in MT4.0 alpha). In Xcode, you can find the setting by clicking on your Target, and looking under Build and searching for "thumb". Mine is under GCC 4.2 - Code Generation, but sometimes it is under LVVM GCC 4.2.