delorie.com/archives/browse.cgi | search |
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 |
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 |
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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |