Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Jan 2000 18:39:03 -0800
From:      Jason Evans <jasone@canonware.com>
To:        Iani Brankov <ian@bulinfo.net>
Cc:        hackers@freebsd.org, Daniel Eischen <eischen@vigrid.com>
Subject:   Re: The stack size for a process?
Message-ID:  <20000117183902.B27689@sturm.canonware.com>
In-Reply-To: <3883D1BB.391C9F0C@bulinfo.net>; from ian@bulinfo.net on Tue, Jan 18, 2000 at 04:36:43AM %2B0200
References:  <200001180055.TAA17507@pcnet1.pcnet.com> <3883D1BB.391C9F0C@bulinfo.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 18, 2000 at 04:36:43AM +0200, Iani Brankov wrote:
> Daniel Eischen wrote:
> > 
> > > Hi,
> > >
> > > after making world of a CURRENT cvsupped yesterday, one of my
> > > applications stopped working because of a Segmentation fault.
> > >
> > > The C procedure where the problem pops has about 64k local variables.
> > > here's the assembly output of the procedure's beginning:
> > >
> > > 0x805bb60 <transaction_read_objects>:   pushl  %ebp
> > > 0x805bb61 <transaction_read_objects+1>: movl   %esp,%ebp
> > > 0x805bb63 <transaction_read_objects+3>: subl   $0x1000c,%esp
> > > 0x805bb69 <transaction_read_objects+9>: pushl  %edi
> > >
> > >
> > > The Segmentation fault happens when the process tries to push %edi in
> > > the stack, which has been just decreased by 0x1000c.
> > 
> > Are you using threads?
> > 
> 
> Yes, it does.
> Do all the threads in a process use the same stack segment in some
> way?

Thread stacks have a default size of 64kB.  libc_r now uses growable stacks
with "guard pages" between stacks to try to catch stack overflow.  It looks
like it did you some good. =)

You will need to specify an alternate stack during thread creation to get
around this size limit, or you can just use less stack space.

Jason


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000117183902.B27689>