From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Peculiar behavior of program.
Date: Tue, 26 Jun 2001 21:25:02 +0100
Lines: 29
Message-ID: <3B38EF9E.4FA60697@phekda.freeserve.co.uk>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010625154252 DOT 2920H-100000 AT is> <3b37e2d6 DOT 287121289 AT news DOT primus DOT ca>
NNTP-Posting-Host: modem-62.desitin.dialup.pol.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: news8.svr.pol.co.uk 993586885 19694 62.136.89.62 (26 Jun 2001 20:21:25 GMT)
NNTP-Posting-Date: 26 Jun 2001 20:21:25 GMT
X-Complaints-To: abuse AT theplanet DOT net
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hello.

Graaagh the Mighty wrote:
> > That would require to use a separate selector for the stack (because
> > the stack is expand-down, and so needs a special segment setup for
> > detecting stack overflows).  This is possible, but has a serious
> > problem: you cannot use -fomit-stack-pointer, because the EBP register
> > will trigger a GPF if loaded with a value larger than the stack size.
> 
> That suggests to make such a scheme be used when code is compiled with
> -g and not -fomit-frame-pointer. If stack smashage is suspected, the
> programmer can just use -g and disable -fomit-frame-pointer.
[snip]
> When it's debugged, they can turn the optimization back on for making
> the production code.

So you want different behaviour when compiled with -g and without? That
could make debugging an interesting experience. I think this kind of
behaviour would be a hinderance more than a help.

Have you tried putting a limit on the recursion in your program, to see
whether that stops the stack overflow? Maybe that would at least help you
debug?

Bye,

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/