delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/02/06/07:40:47

X-Sybari-Trust: d334ce4b 9ffcebbb 22f6c2a2 00000138
From: Martin Stromberg <eplmst AT epl DOT ericsson DOT se>
Message-Id: <200302061238.NAA19735@lws256.lu.erisoft.se>
Subject: Re: Checking for stack overflow
To: djgpp-workers AT delorie DOT com
Date: Thu, 6 Feb 2003 13:38:06 +0100 (MET)
In-Reply-To: <Pine.OSF.4.51.0302061333090.25864@sirppi.helsinki.fi> from "Esa A E Peuha" at Feb 06, 2003 02:04:02 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Esa said:
> On Wed, 5 Feb 2003, Eli Zaretskii wrote:
> 
> > Why not jump to __djgpp_traceback_exit instead?
> 
> After printing "out of stack", you mean?  Maybe, but the traceback
> doesn't seem very useful to me in this case.

That would give the coder a pointer to where the stack was
overflown. That could be useful.

> Here's another thought: how about having an uncommitted memory page just
> below the stack?  Then stack overflow would be just like dereferencing a
> null pointer; caught with no run-time overhead (but only on DOS machines
> unfortunately).

Except that wouldn't catch "void f(void) { int my_array[1024*1024];
my_array[2*1024] = 0; }" or similar.

Perhaps if we reserved 1GiB or something below the stack. But then we
wouldn't catch "my_array[2*1024*1024*1024] = 0"; plus that's starting
to inhibit the real code space. OTOH, perhaps that's ridiculous?

Still it'll only work in plain DOZE.


But that stack check option sounds good.


Right,

						MartinS

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019