Re: Strange behaviors when debugging 'release'

From:

"Tom Serface" <tom@nospam.camaswood.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Thu, 12 Mar 2009 08:13:38 -0700

Message-ID:

<37FD300B-B6AD-4811-8311-1FCBD270024C@microsoft.com>

The problem is you can't trust the "watch" values of variables in a release
build or the current line you're on in the source unless you don't do any
optimizations.

You could debug by using a log file, Trace statements, or AfxMessageBox() to
check the real state of these variables.

The debug build will initialize statics for you, but that doesn't seem to be
your problem here.

Tom

"BoHuang" <BoHuang@discussions.microsoft.com> wrote in message
news:C3DADA26-887C-4B62-9A49-D1206828F2F5@microsoft.com...

I am able to debug 'release' but strange behaviors occur, which are not
present in 'debug'. Are they more likely to indicate inherent problems
obscured by 'debug' such as memory corruption, or the program database is
corrupt for 'release'?

1)
static const int var1 = 64;
static const int var2 = sqrt(64);
static const int var3 = var2 * var2;

Sometimes var3 becomes 0 when inspectedin the debugger, causing crash.
var1
and var2 are unchanged. If I redeclare var3 without the 'static' modifier,
so
far have not encountered it becoming 0.

2)
if( proc == 0 )
{
//path 1
}
else
{
//path 2
}

The debugger shows proc is 0, but stepping forward execution goes into
path 2.

3)
An 'access violation at 0x00000005' type crash is typical of null
pointers.
In the debugger I see somePtr is NULL but the crash does not happen on
line
15 but at line 100 where data from stack created object is accessed. In
between the lines somePtr's value is not altered.

somePtr->getData(); //Line 15

for( int i=someStackVar.begin(); i<someStackVar.end(); i++) //Line 100