Sign in to follow this  
Etnu

Basic run time check options (Visual Studio question)

Recommended Posts

Ok, so I've been having this weird problem with release builds for the last couple of days now. It seems that unless I compile with /RTCs, I'll get a fatal exception before WinMain() is called. From the MSDN documentation:
Quote:
/RTCs Enables stack frame run-time error checking: Initialization of local variables to a nonzero value. This helps identify bugs that do not appear when running in debug mode. There is a greater chance that stack variables will still be zero in a debug build compared to a release build because of compiler optimizations of stack variables in a release build. Once a program has used an area of its stack, it is never reset to 0 by the compiler. Therefore, subsequent, uninitialized stack variables that happen to use the same stack area can return values left over from the prior use of this stack memory. Detection of overruns and underruns of local variables such as arrays. /RTCs will not detect overruns when accessing memory that results from compiler padding within a structure. Padding could occur by using align, /Zp, or pack, or if you order structure elements in such a way as to require the compiler to add padding. Stack pointer verification, which detects stack pointer corruption. Stack pointer corruption can be caused by a calling convention mismatch. For example, using a function pointer, you call a function in a DLL that is exported as __stdcall but you declare the pointer to the function as __cdecl.
So, of course, the obvious explanation here is that I'm getting stack corruption somehow, and the switch is preventing that, right? Ok, fair enough. But it doesn't seem to be indicating anywhere where the corruption is occuring (no warnings, no errors, etc). I checked all my functions, and nothing seems to be putting more than a few KB on the stack. Overruns are, of course, possible, but I thought that the buffer overflow checks were supposed to warn you if that happened. Maybe not. I though "maybe it's a recursion problem", but then I noticed that I'm simply getting a fatal exception error when the program first loads -- before WinMain is called, even. The problem seems to ultimately manifest when memcpy gets called. I tried using all versions of the CRT (multithreaded, single threaded, release, and debug), and the effect was pretty much the same (though of course with the access violation occuring at different locations). Anyone else have anything similiar happen? Anyone know where I should start to track this thing down and get rid of it?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this