From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10302061441.AA20682@clio.rice.edu> Subject: Re: Checking for stack overflow To: djgpp-workers AT delorie DOT com Date: Thu, 6 Feb 2003 08:41:59 -0600 (CST) In-Reply-To: from "Esa A E Peuha" at Feb 06, 2003 02:04:02 PM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Precedence: bulk > > 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. Sure, it shows what routine caused the overflow, and if the overflow was caused by a big automatic allocation or some recursive routine which has recursed forever. > > I don't think we should have this working by default, only given some > > switch to GCC. Stack checking is a run-time overhead, so we shouldn't > > force it on users, IMHO. > > Gcc already has -fstack-check for this; it just doesn't do anything > useful currently. I think it would be good to support this. I'd be willing to help hack the needed global variables out if you did the rest. We really need to be able to make sure that the right signed/unsigned behavior is done with this or it's not very useful (big automatic arrays can cause ESP to not only go into data or code, but actually below 0 and into uncommitted space). > 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). A single page only helps the recursive type behavior - even an automatic allocation of 5K may miss the page if it's not all used. I actually provided the uncommitted memory block once to someone (it can be done in user code) - you set the stack size to be 2X normal size then uncommit the bottom 1/2. It caught many problems, but missed some, and was a DOS only fix. There once was latent support in V2.x for the same hack we used in V1.x to detect this - the stack selector is marked as expand down and has a limit which is the "bottom" instead of the top. This works well in many cases, has no run-time issues - but doesn't work with -fomit-frame-pointer. There are places you must be careful about assumption that SS=DS (not true in limit sense anymore since SS is restricted). The DS alias stuff is similar to what is needed (or may work as-is) - and was based on the GO32 hack to make the SS limit work. This can also be tested in user mode if I remember correctly (but was last probably done in V2.0 beta 3) and also works fine on all platforms, not just DOS.