🚀 go-pugleaf

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.

Ken Walter

In article <4470k6$147l@navajo.gate.net>,
   stidev@news.gate.net (Solution Technology) wrote:
>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.
>

There are a few other possibilities. Check for any differences between your 
Debug and Release compiler and linker settings. Frequently, optimization is 
turned off during debugging to keep the instruction pointer from going all 
over the place as one is tracing through the code in the debugger, and it is 
turned back on to get smaller, faster code. As we all know, optimization bugs 
(and coding problems revealed by optimization) are not unheard of.

Another possibility is a different, smaller stack size for the Release link. 
The GPF you are seeing could be a result of stack overflow. By the way, what 
is the exact GPF you are seeing? There are several different kinds, and it 
might help pinpoint the problem...



Torsten Hoff
thoff@symantec.com

(The views and opinions expressed here are my own,
and should not be construed as representing those
of Symantec Corp.)

On 25 Sep 1995, David Preece 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?
> 

From what I know, the answer is "sort of". 'Doze *detects* such 
violations but does not necessarily stop them. It then kills the 
offending program by way of a GPF (after the damage has been done). 
That's why 'Doze tends to be unstable after GPFs.

> 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.

There is probably a bug in there. Sometimes seg. violations go 
undetected, since even though a program is writing to the wrong part of 
memory, it may still own that memory. However, when you eliminate the 
extra debugging code, the program may end up straying outside its bounds. 
Look for stray pointers and the like.

- Trung

> The GPF you are seeing could be a result of stack overflow. By the way, what 
> is the exact GPF you are seeing? There are several different kinds, and it 
> might help pinpoint the problem...
> 
> Torsten Hoff
> thoff@symantec.com

The exact GPF in question is of the 'An error has
ocurred in your application, Ignore/Close' then 
'Application FOO caused a General Exception
Fault in module BUGGED.EXE at 0002:690B'.

By looking at the address in the .map file, it is
aparrently a part of the CString class:

0002:6900       ??4CString@@RECAFV0@AFV0@@Z
0002:6930       ??4CString@@RECAFV0@PFD@Z

Still, I shall continue to search for stray and
uninitilised pointers etc. If that doesn't work, I
shall just comment bits out until it works...

Thanks to everyone who has contributed to this thread.

David Preece  :-)

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
 */

***** Viet-Trung Luu <vluu@napier.uwaterloo.ca> wrote:

>On 25 Sep 1995, David Preece 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?
>> 

>From what I know, the answer is "sort of". 'Doze *detects* such 
>violations but does not necessarily stop them. It then kills the 
>offending program by way of a GPF (after the damage has been done). 
>That's why 'Doze tends to be unstable after GPFs.

Close.  The Intel x86 processors that implement memory protection (286+)
have a processor trap, 0x0D (13) that is triggered whenever a memory
access violation takes place (that is, accessing memory you do not own.)
The program accessing memory it shouldn't, the processor triggers the trap.

Its possible to register a handler for a system trap, and this is how Windows,
OS/2, and the various flavors of PC unix deal with this sort of thing.


>> 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.

>>There is probably a bug in there. Sometimes seg. violations go 
>>undetected, since even though a program is writing to the wrong part of 
>>memory, it may still own that memory. However, when you eliminate the 
>>extra debugging code, the program may end up straying outside its bounds. 
>>

Sorry, but not quite right.  A segmentation violation (GPF, trap 0x0D, cannot
go undetected.  If it occurs the processor will notice it.  Now, if you 
are running in 386 protected, or FLAT model and allocate say n bytes, where 
n is less than 4096, then you still get a whole page.  You can walk past your
n bytes, but when you cross the page boundary, look out, page fault, and if
you haven't dealt with the page fault trap, segmentation fault, GPF, trap 0x0D.

If its not detected, its not a trap/GPF/seg-v.  Its just a nasty bug.

If you are in 286 (protected) mode, then you are working in segments.  You ask
for an n byte segment, where n < 64k, and you get that many bytes.  As soon
as you cross it, * BAMF * you're toast.  This is the only nice feature about the
intel 286 (protected) mode.

**** for the original poster

Its possible that you are overrighting a page that has been allocated to hold
debug symbols, and when you aren't debuggable, then the page isn't there, and
* KABOOM *.

These kinds of things aren't C++ issues, this post does not belong here,
I did not write it. (floyd, please have mercy, don't make me a bimby...)


-- dave
--

    |||||    Dave Raymer is raymerd@onramp.net (reply-to is wrong)
   ( 0 0 )   The opinions expressed are mine, Mine ! MINE !!!  
-000o---o000-----------------------------------------------------------------  
             "Welcome back my friends, to the show that never ends..."  EL&P

On 26 Sep 1995, David Raymer wrote:
> >From what I know, the answer is "sort of". 'Doze *detects* such 
> >violations but does not necessarily stop them. It then kills the 
> >offending program by way of a GPF (after the damage has been done). 
> >That's why 'Doze tends to be unstable after GPFs.
> 
> Close.  The Intel x86 processors that implement memory protection (286+)
> have a processor trap, 0x0D (13) that is triggered whenever a memory
> access violation takes place (that is, accessing memory you do not own.)
> The program accessing memory it shouldn't, the processor triggers the trap.
> 
> Its possible to register a handler for a system trap, and this is how Windows,
> OS/2, and the various flavors of PC unix deal with this sort of thing.

Hey, I wasn't being technical! However, was I right in saying the 'Doze 
doesn't actually protect the memory, but just detects violations? (Which 
is one reason why 'Doze isn't a robust multitasker, I think.)

> Sorry, but not quite right.  A segmentation violation (GPF, trap 0x0D, cannot
> go undetected.  If it occurs the processor will notice it.  Now, if you 
> are running in 386 protected, or FLAT model and allocate say n bytes, where 
> n is less than 4096, then you still get a whole page.  You can walk past your
> n bytes, but when you cross the page boundary, look out, page fault, and if
> you haven't dealt with the page fault trap, segmentation fault, GPF, trap 0x0D.
> 
> If its not detected, its not a trap/GPF/seg-v.  Its just a nasty bug.
> 
> If you are in 286 (protected) mode, then you are working in segments.  You ask
> for an n byte segment, where n < 64k, and you get that many bytes.  As soon
> as you cross it, * BAMF * you're toast.  This is the only nice feature about the
> intel 286 (protected) mode.

What I want to know is where the debug information in a 'Doze program is 
stored (while running). If it's in memory that's owned by the program, then 
what I said may apply.

> Its possible that you are overrighting a page that has been allocated to hold
> debug symbols, and when you aren't debuggable, then the page isn't there, and
> * KABOOM *.

I thought that was what I was saying... ;-)

> These kinds of things aren't C++ issues, this post does not belong here,
> I did not write it. (floyd, please have mercy, don't make me a bimby...)

I agree. Please don't follow up this post. I am eternally sorry for 
replying to this post (on this newsgroup).

- Trung