Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!gatech!concert!sas!mozart.unx.sas.com!torpid.unx.sas.com!sastdr
From: sastdr@torpid.unx.sas.com (Thomas David Rivers)
Subject: Re: Gcc 2.3.3 bug ?
Sender: news@unx.sas.com (Noter of Newsworthy Events)
Message-ID: <C54I6I.16C@unx.sas.com>
Date: Wed, 7 Apr 1993 17:06:16 GMT
References: <1993Apr6.154454.22346@cm.cf.ac.uk> <1pslf0$so8@usenet.INS.CWRU.Edu> <1993Apr7.104037.21294@cm.cf.ac.uk>
Nntp-Posting-Host: torpid.unx.sas.com
Organization: SAS Institute Inc.
Lines: 60
In article <1993Apr7.104037.21294@cm.cf.ac.uk> paul@isl.cf.ac.uk (Paul) writes:
>>In article <1993Apr6.154454.22346@cm.cf.ac.uk> paul@isl.cf.ac.uk (Paul) writes:
>>>I was trying to port someone elses program to 386bsd but I kept getting
>>>seg. violations which I finally tracked down to an array declaration.
>
>Ok, it's pretty obvious (it always is when you find it :-)) that the
>array declaration is taking up more space than the stack size. The
>result is that the stack pointer ends up pointing outside the process
>space and causing a seg trap.
>
>The problem now is what can we do about it. It took me quite some time
>to find the problem in the first place, I tend to assume that seg
>violations are caused by pointer problems or array bounds so it took a
>while to see what was happening. From what I can find out gcc keeps
>pushing data onto the stack willy nilly regardless of what the stack
>size is. Eventually you're bound to hit the stacksize limit regardless
>of how big you set it.
>
>Can anyone report whether this problem happens with other compilers. If
>not how do they get around it. Causing segment traps when the stack
>fills up is not a very nice way to report this problem and certainly
>does not aid debugging. I tried to think of ways to get around this and
>the only one I can think of is for gcc to check the stack size during
>compilation and use it as a limit for putting data on the stack. If the
>stack size gets exceeded then the comiler should issue an error during
>compilation. At least this way you know that there's a problem and can
>either modify your program or increase the stack size. It's not perfect
>(is there any way to set the stacksize from within an executable) but
>it's a lot better than blindly stuffing the stack until a trap occurs.
>
>Any comments??
>
>
>--
> Paul Richards, University of Wales, College Cardiff
>
> Internet: paul@isl.cf.ac.uk
Well, it's probably not a good idea for GCC to check the compile-time
stack limit - it has a small probability of being anywhere near the
run-time stack limit of the program being compiled.
It seems to me to be pretty reasonable behaviour (there are many
examples of C implementations which exhibit this exact behaviour.)
The reason the same sequence of code doesn't die on LINUX and others
is either:
1) The run-time stack size is set to a high limit,
2) They don't bother checking.
- Dave Rivers -
(sastdr@unx.sas.com (work))
(rivers@ponds.uucp (home))
--
UPDATE ALL INFORMATION AND POD INTO COSMOS - Federal Express