Running Cocoa app under otest causes dyld_misaligned_stack_error in Release mode - objective-c

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.

Related

C++ executable crash

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.

Is it possible to make an Objective-C project (no UI, no simulator) to be tested on Travis (travis-ci.org)?

I wonder if it is possible to make an Objective-C project (no UI, no simulator is needed, hosted on Github) to be built on Travis?
Current Travis docs seems not to contain any information regarding the option to have Objective-C projects built on Travis.
But Building a C Project says that:
Travis VMs are 32 bit and currently provide
gcc 4.6
clang 3.1
core GNU build toolchain (autotools, make), cmake, scons
and that default test script is run like
./configure && make && make test
So, to rephrase the subject question:
Do any workarounds exist to make SenTestingKit test suite, that my project currently uses, behave like a C test suite, so it could be treated as such by Travis VM?
NOTE 1: Here is the list of resources, which seem to be related to the question:
Compiling Objective-C without a GUI. It claims that Both gcc and clang compile Objective-C 2.0 and that sounds very promising!
NOTE 2: I suspect that it is possible to use some testing tool other than SenTestingKit:
this tool should be easy to be run without a GUI and without xcodebuild etc: I've opened related issue for that: Is there any non-Xcode-based command line testing tool for Objective-C?. I am even thinking about writing an easy one just to be used by my project.
A few days Travis announced that they are now also supporting objetive-c projects. See Building An Objective-C Project for more info.
Update
It is even possible to make Travis launch the simulator so that you can run application tests and UI related stuff. I required a little extra work, but it's pretty straight forward. I wrote about it here.

Does xcodebuild command have some options about C++ compile options?

When I used Xcode 4.6 preview verion or xcodebuild command, I had a such error below.
invalid suffix on literal; C++11 requires a space between literal and identifier
However When I used Xcode4, there were no errors.
I don't have much knowledge about C++ and the compiler, so I couldn't find the answer from Internet.
Would you tell me how can I avoid the error with xcodebuild command?
If you invoke xcodebuild from the cmd-line, it should be essentially the same as building the target from within Xcode's IDE.
The only difference that I can think of is that running from the cmd-line will default to Release configuration, whereas inside the IDE will probably use debug. (These can be overridden in both cases).
Could it be that you have a different C++ flags for Debug and Release, and this is making it not work? Try building your project with Release mode inside the IDE, and see what happens.

Xcode Release configuration behaves different

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.

How to debug a GNUstep application?

I'm just starting to learn Objective-C using GNUstep on Windows and I'm wondering what type of debugging options are available? I'm using make to compile and link the code, but once I run the app there doesn't appear to be a way to step through code and inspect variables, the call stack or whatever. Now this isn't the end of the world if I could just figure out how to write to standard output in the shell or to some kind of visibile log window, but calling printf and NSDebugLog doesn't seem to work when running a GNUstep application.
You should most probably use GDB (maybe the MinGW variety), as mentioned in GNUstep documentation.
Note also that GDB has numerous front-ends, which can provide a more pleasant debugging experience. (including Emacs and Eclipse)