I'm making a iPhone App written in Objective-C using the Cocos2d game engine.
I'm using Xcode v3.2.1 with the 3.1.2 iOS. At this point I have always ran my project under Debug Configuration. When I set it to release configuration certain elements of my game are no longer behaving correctly.
My logic that worked in the debug configuration doesn't work in release configuration. What makes release configuration behave differently and what about release configuration would cause problems in the code. This holds true on both the simulator and an actual device.
I'm thinking it may be something within one of my loops, but I'm not sure. Is there guidelines that should be followed under release configuration that are different then debug configuration?
I also ran a Build and Analyse thinking perhaps I was doing something I shouldn't but it came up clean.
Differences between release and debug builds are often caused by uninitialized variables.
Related
I tried to generate an executable code for my program but it always crashes. It was okay in release / debug mode. This is the only change I have done based on the website http://xoax.net/cpp/crs/visualcpp/lessons/CreateExe/
When choosing release configuration the run time library should be Multi-Threaded.
In debug configuration you should choose Multi-Threaded Debug.
I'm trying to create a way to be able to distribute a beta version of my app via Testflight without overwriting the production version. I'd like to be able to know in the code whether it's a beta build or a production build (i.e. somehow define #if BETA_VERSION, similar to the global DEBUG variable), and I'd like to be able to differentiate it with a separate app icon on the springboard, as well as a different app name (i.e. MyApp Beta or similar).
I set up a beta configuration by duplicating my release configuration, and I already have a provisioning profile for AdHoc builds (I've been distributing via Testflight for the last six months or so). I know that to change the app name I need to change the bundle display name property in the project's plist file, but I'm not really sure how to make a separate "profile" to hold all of these changes.
I've tried reading through this article, but I couldn't get it to work and I inadvertently messed up all my provisioning profiles when going through the instructions.
I've been struggling with this for a few weeks now. The details of this process are pretty opaque, so any detailed instructions or pointers are particularly appreciated.
Thank you in advance!
PS it probably doesn't help that I'm really confused about the relationship between targets, schemes, and configurations in Xcode.
I use three configurations in my project: Release, Beta and Debug, where Beta is a duplicate of Release. In each of the three configurations, I'm including the following in my target's build settings:
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) CONFIGURATION_$(CONFIGURATION)
What this will do is define a separate preprocessor macro for each configuration. In your code, you can then do the following:
#if defined(CONFIGURATION_Beta)
// Something that should only happen in Beta builds
#endif
You can define additional build settings per-configuration in the “User-Defined” category (at the bottom of the build settings in Xcode), and then reference them in your Info.plist file. For example, you could define a custom BUNDLE_ID build setting that's different for Release, Beta and Debug builds, and then set the value of CFBundleIdentifier in your Info.plist file to ${BUNDLE_ID}, which would allow you to install Release, Beta and Debug builds side by side on your device.
Update:
If you want to see a good example of how to set all of this up, check out the project configuration in Cheddar for iOS.
I have an OSX application written in Objective-C/Cocoa using xcode. The application is quite finished, tested and sold on the App Store.
I haven't worked on this application for some time and recently, I rebuilt it using xcode 4.3.3 on my OSX 10.7.4 and I noticed that while it builds just fine, there are some very strange visual glitches when running the application that were never seen before and occasionally, I get EXC_BAD_ACCESS when closing the application. All these seem to be related to the PDFKit framework I am using. I am unable to debug these problems since the glitches are just visual (nothing I can check in code) and EXC_BAD_ACCESS exception comes from internally allocated objects not related to my code.
The code itself haven't changed, I tried previous revisions of the code and they all exhibit the same strange behavior now. I tried running an old binary I have of the application (compiled couple of months ago) and it works just fine. Then I tried building it with previous versions of xcode, down to 4.2.1 (which I know was ok when I submitted the app to the app store) and the problems still occur.
Then I suspected this may be something specific to my environment so I built the project on different machine also with xcode 4.3.2 and OSX 10.7.4. Same results, the problems are still there.
So now I suspect that it has something to do with the OSX 10.7.4 update since this is the last thing that was changed between now and when I was able to produce a good build of the application. I am pretty puzzled to what to do next and how to identify the cause of this problem. I have an old binary that is working fine and I have a newly compiled binary of the same code revision that has problems.
Is there any useful information I can get from the difference of these binaries? What can I do to determine the cause of these problems? What can I try next?
Thanks!
NOTE (update): I stated it above but I want to make sure it is clear. This is a Mac OSX Cocoa application, not iOS.
just reset your simulator then try.
I hope you check the ARC information
go to your project Target set build settings --> Search Paths-->Always Search User Paths Set Yes.
And check your all class variables different from one another.
Xcode--> preferences-->Documentation check installed core Libraries (or) install it
like that
Xcode--> preferences-->Components check required component installed or not
check these things in your project.
Are you sure your customers are not having the same problem? Since you have tested the application on a different machine you probably do not have corrupt libraries installed (unless you did not install from scratch but used some migration tool?), so that is probably not the problem.
Most logical explanation to me would be that your customers also have this problem but they haven't reported it yet. In that case, you probably have a memory problem and there are techniques to attack that.
In any case, eliminate all the parameters that you can eliminate to simplify the problem. Deconstruct the application until the problem does not occur anymore or reconstruct the application in a different project until the problem occurs again.
It sounds like a nasty one, but you'll get there in the end, with patience and perseverance :)
First of all, you need check and verify the build log for suspicious compiler warnings.
For EXC_BAD_ACCESS, XCode analysis will give useful information.
You could try 10.6 or 10.5 (need manual installation) SDK. Or restrict the deployment target to 10.5 or 10.6.
I will answer my own question (since none of the above answers really answer it) so anyone with a similar problem might have a hint. I was not able to understand why exactly this happens but I'm pretty sure this is not a problem with my code but rather some glitch on Apple's side. And there is a workaround.
First, I compiled Apple's sample "PDF Annotation Editor" project on my Lion 10.7.4 and while the functionality is obviously different from my project, it also exhibited similar glitches with the PDFView display that my project does when compiled with 10.7.4
Then I proceeded to building a fresh clean system on new hard disk. Intalled Snow Leopard and upgraded to 10.6.8 and ONLY installed xcode. Compiled my project (the source code always stays exactly the same) and everything works fine. No problems seen in the compiled project.
Updated my OSX to Lion 10.7.4 and xcode 4.3.3, same source code. The problem is there after I compile it. I am pretty sure that if I tried 10.7.3 first, I would not see the problem as I remember it only starts with 10.7.4 but Apple doesn't provide any reasonable way to update to 10.7.3 first or downgrade to it after 10.7.4 is installed (shame on them, not very developer friendly!).
So, the problem appears in 10.7.4.
Then I installed the pre-release version of 10.7.5. This was the only thing that was changed, same source, same xcode. To my surprise, the compiled code works flawlessly now and the problems seen with 10.7.4 are now gone!
So my workaround - wait for 10.7.5 release before working on the project further. Hopefully Apple won't screw it in the future with Mountain Lion. I don't think I am going to try and debug it further or submit a ticket to Apple, going to be a tough case to explain.
Thanks for the responses.
I recently did some research on making a cocos2d app for iPhone/iPad AND Mac. I have done the iPhone/iPad route but have never done it with a Mac target. It appears that some people have added it as a target but mentioned that it is finicky and others have suggested making a separate Cocos2d Mac project that uses the same files. Any wisdom to impart here?
I believe it is absolutely crucial to have both iOS and Mac targets in the same project. Otherwise you'll spend too much time keeping one platform in synch with the other, until eventually you either manage to create a good (but still time-consuming) workflow - or end up neglecting one of the two platforms.
Ideally the code base should make as little use as possible of compiler macros. You'll want to compile both iOS and Mac code even if it's not being used for one platform. So having some classes or methods that are #ifdef'ed to Mac, others to iOS, will more often than not lead to compile errors when you switch targets. That means wrapper classes, so that you can write the same code regardless of the platform, are essential.
Right now, Cocos2D doesn't offer you to create iOS & Mac targets in the same Xcode project. The way to get there isn't immediately obvious either, because each target requires its own build settings for: Base SDK, SDK Root, Deployment Target, Architectures and possibly Compiler version. It gets worse if you also want to use 3rd party libraries (Box2D, Chipmunk, etc) because in some cases you'll be forced to create iOS and Mac specific targets for those libraries as well - if only to ensure that the library is built with the same compiler as the project's target, otherwise you can run into the strangest build or runtime issues.
I've had issues getting these platform specific targets to work within a single Xcode project without Xcode complaining or otherwise misbehaving. I haven't tried it with Xcode 4.1 and 4.2. By that time I had created .xcconfig files to host the build settings. The .xcconfig files may or may not be necessary with the more recent Xcode versions but they definitely make managing multiple platform-specific targets easier.
Long story short, the best and easiest way to do cross-platform development with cocos2d-iphone is by using Kobold2D.
Most of the 15 template projects have an iOS and Mac target in each project, you just need to select the corresponding scheme, then hit build & run. The most commonly needed platform-specific code (processing user input) is wrapped in a platform-agnostic, simple to use wrapper class KKInput.
Disclaimer: I'm the developer of Kobold2D. There's a slim chance that I may be biased. You should try Kobold2D anyway. :)
I have a problem which I have been struggling with for a while.
I have a Cocoa library which acts as a wrapper for a C++ library. C++ library is tested using a set of BOOST unit tests. The tests run normally under both debug and release modes.
In order to test the Cocoa wrapper I am using otest. Here is the strange part, the tests run normally in debug mode but fail in release mode. To make sure its not something in the code I've taken the tests content and compiled them as a separate Cocoa app which uses the wrapper code. This runs normally both under release and debug.
When otest fails I get a stack trace which makes little sense and ends with dyld_misaligned_stack_error.
Another strange thing that I've noticed is that when starting otest from a command line rather than from XCode if I point DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH to the Debug version of C++ library the tests pass. I have confirmed though that all my test code is being compiled with Release flags.
Any help would be greatly appreciated!
Thank you
Try adding flag "-mstackrealign" in C flags in the release version.
-mstackrealign
Realign the stack at entry. On the Intel x86, the -mstackrealign
option will generate an alternate prologue/epilogue that realigns
the runtime stack. This supports mixing legacy codes that keep a
4-byte aligned stack with modern codes that keep a 16-byte stack
for SSE compatibility.
See GCC's man page for reference.