Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!basser.cs.su.oz.au!tmx!pos!runxtsa!bde
From: bde@runx.oz.au (Bruce Evans)
Newsgroups: comp.os.386bsd.bugs
Subject: Re: Gcc 2.3.3 bug ?
Message-ID: <1993Apr10.074528.3957@runx.oz.au>
Date: Sat, 10 Apr 93 07:45:28 GMT
References: <1993Apr6.154454.22346@cm.cf.ac.uk> <1psl7c$1pj1@hal.gnu.ai.mit.edu>
Organization: RUNX Un*x Timeshare. Sydney, Australia.
Lines: 26
In article <1psl7c$1pj1@hal.gnu.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>
>In article <1993Apr6.154454.22346@cm.cf.ac.uk> paul@isl.cf.ac.uk (Paul)
>writes:
>>
>> main()
>> {
>> long int Domain_Class[253][229][2];
>> }
>
>You are obvious overflowing your process's stack limit.
>...
>> 0x6b <main+3>: subl $0x71288,%esp
The default stack (size) limit is 512K (0x80000). On my system, when the
program is run using "env - gdb prog", the stack top is 0xfdc00000
(USRSTACK), the stack base is 0xfdb7e000 (USRSTACK - 512K - 8K), and the
stack pointer at the beginning of the program is 0xfdbeeffc. The virtual
addresses from 0xfdbf0000 to 0xfdc0000 are not being used so the effective
stack limit is 64K less than 512K. The wastage is due to exeve() being
sloppy about sizing the args and environment. I used "env -" to reduce
the effects of having an environment.
Anyway, you have to worry about the stack limit if you want large stacks.
--
Bruce Evans bde@runx.oz.au