i'm working on a big program, wich is an awful mix of C and C++. I'm
on windows XP, with Visual Studio 2008 SP1.
This program works fine in debug mode. But in release mode, there is a
crash without any message, and the catch() block don't catch nothing.
I located the function where the crash occurs. In this function, if i
add this code:
{
std::cout << " *** 1 *** " << std::endl;
vector<int> dum_vect( 520 );
std::cout << " *** 2 *** " << std::endl;
}
std::cout << " *** 3 *** " << std::endl;
the output is:
*** 1 ***
*** 2 ***
<crash>
That means that the crash occurs at the exit of the block, when the
vector is desalocated form the stack.
But why? And why there is no problem in debug, but only in release
mode?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
This is generally indicative of either a corrupted stack or running out of
stack space. I'm suspecting the former. The underlying problem almost
certainly precedes the code you've shown which most likely has done
something that is undefined behavior.
In debug mode, few if any optimzations are applied, so the code may just
happen to run fine, since the stack is organzined differently. When compiled
in release mode, the compiler probably rearanges the stack since it has
moved code around. The rearangement just happens to be one in which the
stack corruption becomes visible.
Well. If there's some (e.g.) memory allocation/deallocation bugs, all
kind of weird stuff'll happen at the strangest moments.
* When you say "crash without any message", do you mean you do not even
get a Windows crash dialogue?
* Do you have any toplevel exception handler in this program that might
catch the error?
- catch(...) + /EHa
- SetUnhandledExceptionFilter (see MSDN)
* How about when you run the _release_ build under the debugger? What
happens then?
* Is your debug/release build built with runtime checks enabled? (/RTC*)
br,
Martin
I encountered the same issue few months ago. The problem was due to
memory corruptions located in a nearly unrelated part of the app. The
code was mis-allocating memory, that got corrupted then and I wasn't
able to create a dummy vector just like in your case.
Hope it helps.
You have an error on line 42 of your code.
That is, you have given us insufficent context to determine what your
problem may be.
Most likely it's stack corruption, caused by a buffer overflow. But
that's just a guess.
Please see FAQ 5.8 for further details on how to ask this question.
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8
se
Cheers
Sfider
Coincidence.
> And why there is no problem in debug, but only in release
> mode?
>
Bad luck.
The title of this message is wrong. It's almost certainly not stack
corruption, but free store corruption. And the code that caused the
problem is somewhere else; it just happens to show symptoms here.
Look for deleting the same pointer twice, or writing beyond the end of
an allocated block. Those are the most common causes of free store
corruption, and the result can be a crash pretty much anywhere after
that when the code calls new or delete.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
1. Why: it is utterly imposible, from the code you posted, to deduce
anything. There is no way in hell that three lines you have cause a
crash. Your problem is elsewhere. the best thing you can do is to
start by running your code under some code product. (What do you mean
by crash, BTW? Under windows, you get a "structured exceptions" of
various types. Is that what you're seeing? If so, try debugging and
inspecting your stack, at "first chance exception".
2. There is almost certainly a problem in debug, you just didn't
happen to see it.
Frankly, you should get no consolation words - code have crashed,
error is not in the code you have shown, and you will have to look
harder to find a bug.
And finally, catch() is not meant to catch crashes (nor it does in
majority of any sane code). It is meant to catch exceptions. Very,
__very__ different thing.
Goran.