X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Thu, 19 Aug 1999 19:33:59 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Subject: Re: stack overruns (was: fixed stack size)
In-Reply-To: <199908191644.SAA11166@father.ludd.luth.se>
Message-ID: <Pine.LNX.3.93.990819193059.22580Y-100000@acp3bf>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, 19 Aug 1999, Martin Str|mberg wrote:

> What if we put a certain value at the bottom of the stack (last
> position of the stack before overflowing) at the time of startup and
> then check this value when exiting and if it's not what was put there
> print "Possible stack overflow". Also add this check in the crash dump
> handling routine and print "Almost certain stack overflow" if the
> value is not right.

Same problem as with the guard page approach: if the stack is overflown,
if will often happen in one large step, without touching all addresses in
between. Think of someone using a double a[200000]; local variable.
Stack corruption happens, but your guard value will only be hit if
that array is actually modified.


Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.