Re: Problem only in release version!

If it is crashing I'd check overflowing of variable space on the stack
(local variables). For example, if you set up a char buffer to hold 10
chars and you add 11 to it. This kind of thing is very easy to do. The
Debug version may still have the problem, but the stack space is better
protected and the memory is not arranged the same so at run time even if the
problem is really still there it may not crash your program.

As others have suggested uninitialized pointers, etc. are flagged at compile
time so you'd see those warnings at least. However, going beyond allocated
memory or a buffer on the stack is not always caught.

Of course, if this is all managed code, that's not supposed to happen, but
VC allows native and mixed which opens it up again.

Tom

"Peter Oliphant" <poliphant@xxxxxxxxxxxxxxxx> wrote in message
news:uxFeKpfzFHA.460@xxxxxxxxxxxxxxxxxxxxxxx
> 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).
>
> 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.
>
> Hope that helps!!! : )
>
>
> "Jochen Kalmbach [MVP]" <nospam-Jochen.Kalmbach@xxxxxxxxx> wrote in
> message news:O9nGQJdzFHA.1028@xxxxxxxxxxxxxxxxxxxxxxx
>> Hi babak!
>>
>>> My project works fine in debug version but behaves strangely and
>>> sometimes crashes when I run it in release version.
>>
>> See: Surviving the Release Version
>> http://www.flounder.com/debug_release.htm
>>
>> Mostly it has to do with uninitialized data (in debug this data will get
>> soe "default" value; but in release it will get some random numbers).
>>
>> --
>> Greetings
>> Jochen
>>
>> My blog about Win32 and .NET
>> http://blog.kalmbachnet.de/
>
>


.

Relevant Pages

  • Re: Problem only in release version!
    ... the Debug version initializes most variables ... to zero. ... the contents of the memory addresses they happen to get assigned to). ...
    (microsoft.public.dotnet.languages.vc)
  • RE: RunAs weirdness...
    ... at least 288 total characters. ... however I was able to see some of my data on the stack... ... point in memory. ... Click CANCEL to debug the program. ...
    (Vuln-Dev)
  • re: RunAs weirdness...
    ... I tested the runas issue that was recently posted on my Win2k build ... however I was able to see some of my data on the stack... ... memory could not be "written" ... Click CANCEL to debug the program. ...
    (Vuln-Dev)
  • Re: Frustrating Lack of support with Sproxy.exe
    ... the Debug version initializes most variables ... to zero. ... the contents of the memory addresses they happen to get assigned to). ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Frustrating Lack of support with Sproxy.exe
    ... > Just to affirm Tomas's point, the Debug version initializes most variables ... > they keep the contents of the memory addresses they happen to get assigned ... > fine if initialized to zero, but don't work if not initialized to zero (or ... > variables) even if it is totally stable in Debug mode. ...
    (microsoft.public.dotnet.languages.vc)