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. :)
Related
I have a simple GWT app.
Whenever I run gwt compilation for production, I also see a file with the extension .devmode.js being generated.
Questions:
This looks like a devmode-related file; do I actually need it while running in production? Do I need to delete it?
What does it do?
If useless, is there any way to stop it from being generated while in production?
I'm using GWT 2.8.
Kind regards,
Andrei
It is specific to legacy Dev Mode, and not used in Super Dev Mode. If you don't ever use legacy Dev Mode, you don't need it.
You don't need it in production... unless you ever need to debug your app in production. If you ever want to debug your app in production (with legacy dev mode), you should leave it.
You do not need to delete it - it will not be used unless you attempt to enter dev mode, and it is a static file, and cannot be used to maliciously debug your app, unless the attacker also has all of your original Java source code already.
The Linker system does not currently have a way to prevent it from being emitted. The "generation" of it is very simple, only the __MODULE_NAME__ tokens are replaced with the name of your app, so there is essentially no penalty paid in creating it.
Unless you need the extra 1k of disk space in your generated app, I wouldn't worry about it at all as there is no risk in having it. If you do need that extra 1k, either modify your current linker to avoid emitting it, or add a later build step to delete it.
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.
This problem has been KILLING me. I've been working on this app for 8 Months, and I am so close to finishing, I just can't seem to build for device. Building for the simulator works fine, but device always gives me the SAME 2 errors.
The 1st Error:
"Instruction requires a CPU feature not currently enabled"
From googling, I've found this probably means I'm not linking a binary I should be, but I'm not sure.
The 2nd Error:
If you can't read it, it says: Generating JWFNS.app.dSYM ... error: unable to open executable '/Users/ajr1188/Library/Developer/Xcode/DerivedData/JWFNS-azshgysfabycfagnebotitpcyaww/Build/Products/Debug-iphoneos/JWFNS.app/JWFNS'
This is the big one. I cannot seem to build the .app.dSYM file properly. I went in and deleted the build folder, I looked at EVERY stackoverflow question I could find and tried changing any random thing mentioned in another question, but all of it is to no avail. I'm so suck right now. AHH. PLEASE. Any help would be so appreciated!
Maybe your project has become hopelessly corrupted. One thing to try is to start a brand new project and copy/import all your sources/assets into the new project to see if that fixes the problem.
Another less nuclear (but perhaps more time consuming) approach is to binary search the build. Exclude absolutely everything except main.m and see if that fixes the problem. If it does, include half your sources, and buid again....repeat, trying to narrow in on the problem spot. Maybe a file or group of files has received special build settings that don't belong there.
I've had very similar problems, I cant remember the exact error message but it was very similar. Are you able to make a new project that will run on your device?
if so (and I know this sounds bad but it's worth a try) Create a new project and simply copy all the code and resources across and see if it still works. If it doesn't then there is something wrong with you code and you can continue trying to isolate the problem from there.
Hope this is helpful.
check the frameworks you link to. there's a chance that you linked a framework (say quartz) of osx, instead of ios.
Answering in detail is probably going to take looking at your target settings. But it looks like you may be building for the wrong architecture. (It doesn't link, so there is no .dSYM symbol file.) For example, if you have only recently built for device, you probably created your project under an older Xcode, and it may not have the arm6/arm7 settings right.
To check, show the Build Settings for your target (not the project), and filter on Architecture.
Make sure that in build settings the architectures are armv6 and armv7. Also make sure that in .plist file, the "Application requires iPhone environment" is TRUE. Delete "Required device capabilities" in the .plist if present.
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?
Motivation — I had a new version of my Cocoa application ready that worked fine on all beta testers' machines. So I released it. Turns out that a crucial feature simply doesn't work on anybody else's computer. Yikes! Yes, read that again: I released software that didn't work.
Cause — Users who had used previous versions my app (read: all my loyal beta testers) already had a folder ~/Application Support/MyApp/ from an older version. Due to the critical bug in the new release, this folder was necessary for the software to work. And for everybody else, because the folder did not exist, it didn't work.
As you can imagine, this is extremely embarrassing, and I want this to never, ever, happen again.
Remedies? — The straight-forward way to ensure this, of course, is to actually download and install it on a "clean" machine just before you publish a new release. But this seems impractical, because in time I will run out of friends with a Mac who have never tried my app yet (eventually all will have ;-)), and because I'm not eager to "format c:" my Mac before every single release…
This is where I need your help:
How can I ensure that a user who has never used my software before will get the same results as someone who has?
Virtual machines (VMWare Workstation, etc.) can be useful for testing clean installs of applications. You can start up a new virtual OS, install your stuff, test it, then delete the VM when you're done. There are ways to automate the spinning-up of a VM as well, which can make your life even easier.
Another thing to do is to determine all the prerequisites your app requires, and add checks for these things at startup. If something is not setup right, you can either attempt to set it up within your code, or inform the user to do it.
A more lightweight approach might be using tools like AppZapper to get rid of everything — temporary files, preferences, cache, history, etc – related to the app to test.