I have a strange problem, I hope you can help me.
I write a program in C++ Builder 2009, when I run the program without debugger I see an Exception raised. bun in debugger never exception raised and I cant find the exception point.
And Also I enable the CodeGaurd in C++ for Finding the problem but the Exception never raised, If I disable codeGuard the exception will be here again.
I use OpenCV and some Delphi units in the program.
And when I compile it I see more than 2 millions of code line compiled.
Thanks in advance for your attentoin.
A few things too look at:
in the IDE options, make sure you are not ignoring some exceptions
debug builds MAY have memory variables set to NULL on run, release builds will not. Make sure you are running the same build (Debug) in both the IDE and without.
Ignore the line count that is displayed, its all those .hpp files that holds the vcl headers.
Related
I'm trying to use ros in cpp with Visual Studio 2012. I wrote the publisher and subscriber tutorial (http://wiki.ros.org/ROS/Tutorials/WritingPublisherSubscriber%28c%2B%2B%29) and first, I configure the project as says in the guide (http://wiki.ros.org/win_ros/hydro/Msvc%20SDK%20Projects).
Then i compiled an linked the publisher, but when I tried to run it, ros::init(argc,argv,"talker") throws an exception... The console says that I ROS_MASTER_URI is not defined but I've got it defined
There are 2 images here:
https://www.dropbox.com/s/o12m0l38gaxiugi/error1.png -
https://www.dropbox.com/s/ocdmf0wj6rj0962/error.png
Can anyone helps me?
Thanks in advance
So, I had the same issue, although I didn't set the ROS_MASTER_URI globally.
I managed to get around this specific issue by adding
ROS_MASTER_URI=http://localhost:11311
to the debugging environment variables (Project->Properties->Configuration Properties->Debugging->Environment).
However, after implementing the above I got an uncaught exception (Unhandled exception at 0x768bc41f in ros_demo.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0028f0e4..).
That went away when I built, compiled and ran the project in release mode (which matched my ROS SDK build).
I got the idea for the release/debug build from here:
xstring isn't an OSG specific object, so the error is elsewhere in the
3rd party dependency chain. As I know nothing about your OS and
software setup I can't speculate what this might be.
In general though this type of error could well be a linking issue -
for instance Visual Studio is hopeless at handling different libs
being built debug and release and will crash randomly.
That was fun to discover..
I am using VS2010.I was changed my project and its dependent projects .Net Framework to 4.0 from 3.5.Now I could not attach the process,due to this I am not able to debug the code.
I have cleaned all the bin folders and rebuild the projects ,but still I am having following error.
Please help me to resolve this..
I'm not sure what the question is here. The error message clearly tells you that you need to
Turn off (disable) optimizations
Turn on (enable) debug info
Rebuild your project so those changes take effect.
Apparently you only did step #3.
Also see vs2010 debugging module was built without debugging information?, which may provide more information.
I also received this error, and did all the right things as described above - those have been my settings all along anyway. I even went so far as deleting the assembly from the long C:\Users... path in the error message - it still didn't cause that message to go away.
Then I tried putting a breakpoint in the source, which should not be allowed if the module really WAS built without debug information. And then ran the program and it stopped at the break point and I could do all the usual debugging.
So right now I'm just ignoring the message. I could do as suggested and disable the 'Warn if no user code on launch' option as suggested in the message, but I'm not doing that until I can spend some time working out why the message comes up at all.
Uncheck this option in Visual Studio 2012.This would solve this issue
I use ndk-build to compile libpng source code in debug mode, then it shows “internal compiler error” in pngrtran.c. But when I compile in release mode, it can success. Is this a bug in libpng? How I can resolve this?
It's not a bug in libpng; anything a program describes as an "internal error" is a bug in the program (libpng does this, but then it shows "libpng: internal error"!) So it's a bug in the compiler.
You should report it to the ndk guys or you could go directly to the compiler vendor (probably GNU) because they would likely to be more responsive.
You can't resolve the problem - it needs a compiler fix (maybe only to output a message that doesn't claim it's an internal error, but at least that.) You can avoid the problem by simply not compiling libpng in debug mode. Since I assume this is for Android so you can (I believe) mix-and-match debug and now debug code (this does NOT work on Windows with at least one compiler!)
You can also try working out which compiler option reveals the problem; compare the options being passed to the compiler in both release and debug, then bisect the differences to see if you can narrow the issue down to one setting.
John Bowler jbowler 2 acm.org
The android team should know about the bug. As Its a resurface of an old one:
http://code.google.com/p/android/issues/detail?id=20862
Compilation of my code in both modes debug and release is successful. Debug mode execute and works fine, but when i execute release mode, it says "the application was unable to start correctly 0x80000003".
What is this error and why debug mode works fine but not release.
DLLs for debug and release are present in the same directory name "bin". "lib" for both modes also placed in the same directory.
I tried to solve it many ways but not succeeded ? Guide me how to solve this issue? Thanks.
why debug mode works fine but not release
Thre can be many reasons why one build works while another doesn't. The shape and size of data structures can be different because of #ifdef or because the compiler emits different code, the code being executed can be different - again because of constructs like #ifdef or because of the code the compiler is emitting.
That can matter when you've got code with a bug in it. Let's say you've got a bug that miscalculates the length of an array (or the size of a structure or whatever). You do some pointer arithmetic and write some data into memory using that pointer - only you're writing to the wrong place. Whether that mistake breaks your program may depend on what was in the memory you overwrote.
If you're lucky your program crashes almost immediately because what you overwrote was important to some code executed immediately after your bug. If you're only a little bit lucky your program crashes some time later in a completely different part of your program because what you overwrote was important to code far away from your bug. If you're really unlucky your program doesn't crash at all until several years later when a completely unrelated change moves things around in memory so now what you are overwriting suddenly is important.
There are lots of other possible causes of what are sometimes called Heisenbugs
What is this error
One place to look for errors like 0x80000003 is the file WinError.h which you'll find in the SDK you are using (either the one that came with Visual Studio 2010 or one you installed later). Look in WinError.h and you'll find that that E_INVALIDARG is defined to be _HRESULT_TYPEDEF_(0x80000003L).
That doesn't necessarily help though because we we don't know enough about what is returning that error or why it is returning that error or even that your 0x80000003 is in fact an E_INVALIDARG - it could be some other error with the same value, or some piece of code mis-using E_INVALIDARG or something else.
Another possibility is that 0x80000003 is a hard-coded breakpoint exception being thrown - most likely because your program has got to one of those "this should never happen" places where the only thing that makes sense is to throw an exception and crash. If you look in NtStatus.h (in the same place as you found WinError.h) you'll find that STATUS_BREAKPOINT is defined to be ((NTSTATUS)0x80000003L)
how to solve this issue
The trick is to figure what is causing the 0x800000003 (and where in your code it is happening) so you can narrow down why it is happening. Most likely it's an exception but why jump to conclusions?
You can run a release build inside the debugger just as you would run a debug build - that is, build the code using the Release target and then press F5 or Debug | Start Debugging. Look in the Output Window and you may see some information that will help you interpret the error.
You can also use the Debug | Exceptions menu to add a new Win32 Exception with the value 80000003 and set that up to break when thrown rather than to break when unhandled. That way you should stop in the debugger when that exception is thrown (if it is in fact thrown).
Of course it could be that even running your program within a debugger is enough to change things so your problem doesn't occur.
I have a workspace for running an H.263 Video Encoder in a loop for 31 times i.e. the main is executed 31 times to generate 31 different encoded bit streams. This MS Visual Studio 2005 Workspace has all C source files. When i create a "DEBUG" configuration for the workspace and build and execute it, it runs fine, i.e. it generates all the 31 output files as expected.
But when I set the configuration of the workspace to "RELEASE" mdoe, and repeat the process, the encoder crashes at some test case run.
Now to debug this is verified following:
Analyzed the code to see if there was any variable initialization being missed out in every run of the encoder
Checked the various Workspace(Solution) options in both the modes (DEBUG and RELEASE).
There are some obvious differences, but i turned the optimization related options explicitly same in both modes.
But still could not nail the problem and find a fix for that. Any pointers?
-Ajit.
It's hard to say what the problem might be without carefully inspecting the code. However...
One of the differences between debug and release builds is how the function call stack frame is set up. There are certain classes of bad things you can do (like calling a function with the wrong number of arguments) that are not fatal in a debug build but crash horribly in a release build. Perhaps you could try changing the stack frame related options (I forget what they're called, sorry) in the release build to the same as the debug build and see whether that helps.
Another thing might be to enable all the warnings you possibly can, and fix them all.
Could be a concurrency problem of two threads. The DEBUG configuration slows the execution down, so the problem does not occur. But, only a guess.
Interesting problem.. Are you sure you have no conditional compilation code lurking around that is not being compiled in release mode? i.e:
#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif
Thats the only thing I can really think of.. Never experienced anything like this myself..
Can you add the debug symbols to the release build and run it in the debugger to see where and why it crashed?
Yeah, those bastard crashes are the hardest to fix. Fortunatly, there are some steps you can do that will give you clues before you resort to manually looking at the code and hope to find the needle.
When does it crash? At every test? At a specific test? What does that test does that the others don't?
What's the error? If it's an access violation, is there a pattern to where it happens? If the addresses are low, it might mean there is an uninitialised pointer somewhere.
Is the program crashing with Debug configuration but without the debugger attached? If so, it's most likely a thread synchronisation problem as John Smithers pointed out.
Have you tried running the code through an analyser such as Purify? It's slow but it's usually worth the wait.
Try to debug the release configuration anyway. It will only dump assemblies but it can still give you an indication of what happens such as if the code pointer jumps in the middle of garbage or hits a breakpoint in an external library.
Are you on an Intel architecture? If not, watch for memory alignement errors, they hard crash without warning on some architectures and those codec algorithm tend to create those situations a lot since they are overly optimized.
Are you sure there are no precompile directives that, say, ignores some really important code in Release mode but allows them in Debug?
Also, have you implemented any logging that might point out to the precise assembly that's throwing the error?
I would look at the crash in more detail - if it's crashing in a test case, then it sounds pretty easily reproducible, which is usually most of the challenge.
Another thing to consider: in debug mode, the variables are initialized with 0xCCCCCCCC instead of zero. That might have some nasty side effects.