Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!pipex!uknet!uknet!cf-cm!paul From: paul@isl.cf.ac.uk (Paul) Newsgroups: comp.os.386bsd.bugs Subject: Re: Gcc 2.3.3 bug ? Message-ID: <1993Apr7.104037.21294@cm.cf.ac.uk> Date: 7 Apr 93 10:40:35 GMT References: <1993Apr6.154454.22346@cm.cf.ac.uk> <1pslf0$so8@usenet.INS.CWRU.Edu> Sender: news@cm.cf.ac.uk (Network News System) Organization: /usr/local/lib/rn/organisation Lines: 36 >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