🚀 go-pugleaf

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