Re: Assertion in DEBUG and RELEASE

On Thu, 28 Apr 2005 21:17:19 +0200, "Guido Stercken-Sorrenti [MVP
VC++]" <mspbn@xxxxxxxxxxxxxxxxxxxxx> wrote:

>> Recently, I came across a situation, that at some point in the code, that
>> my program start crashing BUT only in Release
>> version, that is also not always, but some particular point. Now, you can
>> imagine it is very hard to find such problem. The
>> code is like this, I was getting a pointer, and check with an ASSERT
>> statement that the pointer is valid or not. Now, in DEBUG
>> version, it works fine all the time, even at that particular situation,
>> while debugging or just with run. But release version
>> gives the pointer is invalid, and not throwing any exception or assertion,
>> so I was not able to go to that particular
>> function, or source line quickly. My question is:
>> Is it good to check an assertion at the Release version also? Because MFC
>> ASSERT or CRT LIB's _ASSERT macros will work only in
>> DEBUG version and not in release? But if we use _assert, CRT-L function
>> the it will give assertion in Release version also.
>> So, is it OK to get the assertion also in Release version?
>
>Generally, assertions are used for spotting coding bugs during development,
>not runtime errors. Those bugs should be fixed for a release build, that's
>why assertions (which also make your code slower) are removed from release
>builds.
>
>The reason why your code fails in a release build is most probably an
>uninitialized pointer: The debug CRT initializes that memory with NULL,
>that's why it works in a debug build (if you test against NULL) but fails in
>release build.

In VC7.1 at least, uninitialized data is filled with 0xcc... in a
debug build.

The OP can always add if statements or his own macros that will be
compiled into both debug and release builds.

Note that assert(x=y) (or any assert that modifies anything) will
cause different behavior in debug and release builds.

Also notable (but not necessarily germane in this case): compilers
always have bugs, and the optimizing compilers generally have
different bugs than the debug compiler.

>To spot that kind of bug, see the following FAQ on CodeGuru:
>http://www.codeguru.com/forum/showthread.php?s=&threadid=269905

--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.
.

Relevant Pages

  • Re: Weird error during programme startup
    ... Microsoft Visual C++ Debug Library ... I've stepped through the innards of _initterm and it ... it won't assert in release builds. ... You said that you moved all strings to string tables. ...
    (microsoft.public.vc.language)
  • Re: Tips to hide "Debug Assertion Failed!"
    ... Assert failures only come from the debug version. ... and also represents a bug in your program. ... Joseph M. Newcomer [MVP] ...
    (microsoft.public.vc.mfc)
  • Using debug print routine inside assert
    ... The idea here is to have consistent debug print messages. ... If you could skip the evaluation of debug, ... return True # return true so that assert always succeeds ... nevertheless, in Python, you don't have such thing as macros. ...
    (comp.lang.python)
  • Re: Use of assert.h
    ... Leaving this to assert() is ... so bugs don't get noticed. ... perfectly valid for a _debug_ build to abort when it gets one. ... sense in context and doesn't crash/abort or otherwise lose user data. ...
    (comp.lang.c)
  • Re: behaviour of vector::operator[]
    ... > programming. ... assert to check the precondition. ... Moreover for debug purposes, you ... checks in certain places using some sort of asserts, not exceptions. ...
    (microsoft.public.vc.stl)
Loading