🚀 go-pugleaf

stidev@news.gate.net (Solution Technology) wrote:

>David Preece (dmpreece@tcp.co.uk) wrote:
>: ..I was always under the impression that a GPF was Windoze's way
>: of stopping one application from writing over anothers' memory.
>: Am I right?

>: And if so, why is this happening:
>:   
>:   I am allocating a very complex dialog box on the heap. When compiled
>:   with Visual C++ in debug mode, it executes fine. When compiled in 
>:   release mode (with the compiler and linker options otherwise identical)
>:   this dialog box GPF's.

>That usually indicates uninitialized pointers or data.
>The debugger frequently supplies a zero initial value while
>non-debug running uses the previous contents of memory.

Actually, this is not the case.  The debugger uses 0xC0 (or somesuch),
while the debug and non-debug, while not in the debugger, does no
initialization.

GPFs have many causes, not all fatal.  A thorough discussion would be
far beyond the scope of this group (and my hardware knowledge :]), but
one cause I can think of for the original poster's problem is simply
an optimization bug in the compiler.  Try doing a retail build with no
optimizations.  If that works, keep adding optimizations one at a time
and doing full builds until the problem comes back.  Then avoid that
optimization in the future.  That's the best I can do without sample
code.

>Ken Walter


/* Eric Kenslow - kenslowe@sparky.oit.osshe.edu
 * Oregon Institute of Technology, Klamath Falls, OR
 */