Re: Problem only in release version!
- From: "Peter Oliphant" <poliphant@xxxxxxxxxxxxxxxx>
- Date: Tue, 11 Oct 2005 10:04:24 -0700
So I was right for the wrong reason then.... : )
By the way, another less likely 'source' of the problem is if any of the
application has required code in an 'assert'. Any code in an 'assert' is is
not executed in Release mode (I believe, but I also thought Debug
initialized variables to zero, so what do I know...hehe) .
Most people don't put anything but comparison checks in asserts, and not
functioning code, but you never know... : )
"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:g49mk15kuohdpiqsbls7pdb19mbsc6mugp@xxxxxxxxxx
> On Mon, 10 Oct 2005 17:25:29 -0700, "Peter Oliphant"
> <poliphant@xxxxxxxxxxxxxxxx> wrote:
>
>>Just to affirm Jochen's point, the Debug version initializes most
>>variables
>>to zero. The Release version will not initialize anything 'naturally'
>>(meaning without you writing code to do so), and hence many of the
>>variable
>>are often given a 'random' value upon loading ('random' in that they keep
>>the contents of the memory addresses they happen to get assigned to).
>
> The debug version doesn't initialize anything to zero that isn't
> zero-initialized in the release version. The /RTCs documentation explains
> why you're more likely to observe zero as the value of uninitialized
> stack-based variables in debug builds that don't use /RTCs.
>
> /RTC (Run-Time Error Checks)
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vcrefrtcruntimechecks.asp
>
> In addition, the debug heap manager sets memory to certain non-zero values
> to help diagnose heap errors.
>
>>Thus, your new errors are likely the result of some variable that works
>>fine
>>if initialized to zero, but don't work if not initialized to zero (or not
>>in
>>some range, non-negative, etc.). Since an application doesn't always get
>>loaded at the same place and memory, and because even the same place in
>>memory can have different values depending on when you load your program
>>(that's why it's RAM not ROM...hehe), you can get random bugs and
>>un-stable
>>executions of the Release version (i.e., it might do different things on
>>different runs depending on the 'random' nature of your variables) even if
>>it is totally stable in Debug mode.
>
> The OS (NT-based Windows anyway) only ever hands out memory pages
> initialized to zero. In fact, there's an OS thread whose purpose in life
> is
> to populate a zeroed page list:
>
> Inside Memory Management, Part 2
> http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=3774
> <q>
> Pages on the standby page list move to the zeroed page list after a
> special
> thread, called the zero-page thread, clears their content. The zero-page
> thread executes in the background at priority 0. It runs only if no other
> thread can run, and its job is to move pages from the free page list to
> the
> zeroed page list as it clears their content.
> ...
> The necessity of zeroing a page before assigning it to the working set of
> a
> different process is a C2 security requirement.
> </q>
>
> --
> Doug Harrison
> VC++ MVP
.
- References:
- Problem only in release version!
- From: babak
- Re: Problem only in release version!
- From: Jochen Kalmbach [MVP]
- Re: Problem only in release version!
- From: Peter Oliphant
- Re: Problem only in release version!
- From: Doug Harrison [MVP]
- Problem only in release version!
- Prev by Date: Re: Problem only in release version!
- Next by Date: Re: templates and managed code
- Previous by thread: Re: Problem only in release version!
- Next by thread: Frustrating Lack of support with Sproxy.exe
- Index(es):
Relevant Pages
|
