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.
Related
I am working on valgrind and want to debug a program while valgrind runs over it.
But i don't want to use the in built vgdb, instead i want to use a custom gdb server.
Is there a way to plugin this custom gdbserver in the existing valgrind code.
thanks
Only by patching valgrind. The valgrind gdbserver implementation is compiled in.
We have our code and binaries in Unix box .Few of the binaries are for web packages loaded by CGI .I use gdb in remote debugging mode to debug normal binaries but web binaries are difficult to debug because the process id changes every time the binary is loaded and gdb detaches .I heard in Visual studio there is a option to add in task manager and debug it .But i m afraid if i install Visual studio my system would go slow.Any suggestion on any other opensource tools available for efficient remote debugging of web binaries
The best thing you can do is to efactor the code so you can test most parts of it outside a CGI context with some unit testing system or something similar.
The second step would be to replay the CGI communication manually. It's not complicated - set the environment variables needed and eventuelly pipe the POST data in while running under gdb.
If that doesen't help you have to debug the web server and ask your debugger to follow child processes. Best thing is to start the httpd using the -X option so it runs with a single process itself. Then attach gdb and set the set follow-fork-mode child command. See gdb manual at http://sourceware.org/gdb/onlinedocs/gdb/Forks.html
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.
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.
I'm not that up on VB.NET, the application I'm working on was not written by myself.
It works fine through the IDE but once I run it from the exe it gives me the above error.
Any clues?
This is really hacking me off!
The only user defined break point that I can think of is
Debugger.Break()
So, I would suspect that the .exe is compiled in debug mode. I would recommend Reflector to look at the code and find out for sure whether or not there is a Debugger.Break() somewhere in there.
Afaik, the only way this could occur if you are compiling under debugging settings. You should be able to fix it by doing the following:
Right-click your solution on the
solution explorer.
Select configuration properties.
At the top of the dialog box there should be a
combobox, which will most likely say
"Active(Debug)".
Click on the dropdown and select release.
Ok out of everything.
Build > Rebuild Solution.
Source: p2p.wrox.com
I believe the exe file was compiled using the "Debug" setting. Try changing the Build setting to Release and do a full build (rebuild) of the project. Then try to run the executable file. It should then run normally.
The reason you see that error is because when you normally compile and run applications in Visual Studio, it compiles a Debug build of the executable. The different between a debug build and a release build is that the debug build has additional information added to it, by the compiler, so it can be debugged properly.
I would suggest looking for stop in your code. That is what generated this error for me.