From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9706241842.AA16453@clio.rice.edu>
Subject:	Re: Debugging options
To:	broeker AT physik DOT rwth-aachen DOT de (Hans-Bernhard Broeker)
Date:	Tue, 24 Jun 1997 13:42:38 -0600 (CDT)
Cc:	dz AT bo DOT dada DOT it, djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.LNX.3.91.970624152718.10672C-100000@acp3bf> from "Hans-Bernhard Broeker" at Jun 24, 97 03:36:02 pm

> But something similar is possible, and used by ElectricFence: you can make
> a 'hole' (more technically: a page of unmapped memory) in address space
> behind (or in front) of every malloc()ed block, so that if you write past
> the bounds of an array or something similar, you'll get a page fault. This
> can help, but it's not perfect. If you access further out of bounds, you
> will sooner or later hit the next, existing page of memory behind the
> hole. 
> 
> In DJGPP, this technique would be in danger of overflowing the space
> used for the 'page tables', I suspect.

Nope, been there, done it.  Use sys\mman.h - use PROT_NONE for the boundary
limit pages (4096 byte boundaries) and use PROT_READ for structures you
don't want modified.  Of course, you need CWSDPMI or 386MAX for this, and
a hacked malloc package.  You can use about 1/2 Gb of address space with 
CWSDPMI before the page tables start to fault.

The unused bytes at the end of the page (which can't be protected) should be 
set to some value like 0xde and checked on the free to make sure they haven't 
been modified.

You may find some unix code will work out of the box with this call :-)

- Raw text -