Date: Sun, 25 May 2003 23:31:41 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Andrew MacIntyre <andymac@bullseye.apana.org.au> Cc: alane@freebsd.org Subject: Re: setting stacksize in "initial" thread (pthreads, 4.8R) Message-ID: <Pine.GSO.4.10.10305252329450.14009-100000@pcnet1.pcnet.com> In-Reply-To: <20030526084710.A57768@bullseye.apana.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 May 2003, Andrew MacIntyre wrote:
> On Sun, 25 May 2003, Daniel Eischen wrote:
>
> > On Sun, 25 May 2003, Andrew MacIntyre wrote:
> >
> > > I have a situation with a Python interpreter built from Python
> > > CVS sources that is hitting the stack limit for the "initial" thread
> > > imposed by libc_r: PTHREAD_STACK_INITIAL in
> > > /usr/src/lib/libc_r/uthread/pthread_private.h is set to 1MB (0x100000).
>
> {...}
>
> > Is this something that is common to all python scripts, or is
> > it just your own script(s) that is(are) getting caught. It
> > seems 1MB is an awful lot to be on the stack, and perhaps some
> > things are better malloc'd.
>
> The problem actually occurs with recursive matches in Python's regex
> engine. Python has a hardcoded regex recursion limit, which has trapped
> ballistic matches before running out of the default stack. However a
> couple of recent fixes to the regex engine have increased stack
> consumption, and the hard limit has to be lowered.
How do you know it is the main thread stack and not a different
thread stack that is getting exceeded? By default, threads
other than main get a 64K stack, and this is totally configurable
by the application.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10305252329450.14009-100000>