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
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/

- Raw text -