Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Dec 2002 05:47:24 -0800
From:      David Schultz <dschultz@uclink.Berkeley.EDU>
To:        Varshavchick Alexander <alex@metrocom.ru>
Cc:        Terry Lambert <tlambert2@mindspring.com>, freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject:   Re: maxusers and random system freezes
Message-ID:  <20021206134724.GA16965@HAL9000.homeunix.com>
In-Reply-To: <Pine.GSO.4.33.0212061546090.15512-100000@apache.metrocom.ru>
References:  <20021206123440.GA16544@HAL9000.homeunix.com> <Pine.GSO.4.33.0212061546090.15512-100000@apache.metrocom.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Varshavchick Alexander <alex@metrocom.ru>:
> On Fri, 6 Dec 2002, David Schultz wrote:
> 
> > Thus spake Varshavchick Alexander <alex@metrocom.ru>:
> > > Well, now I made KVA space 2G, we'll see later on if it helps to get rid
> > > of the sudden system halts, but for some reason a side-effect has
> > > appeared: pthread_create function returns EAGAIN error now, so I had to
> > > recompile the software using it with linux threads to make it working.
> > > With the old kernel these pieces worked without problems. Can it be that
> > > somehow the enlarged KVA space messed up with the threads mechanism?
> >
> > I'm not a pthreads expert, but my best guess is that your program
> > tried to create a thread with a stack address that was too high.
> > Remember that with a 2 GB KVA, user processes have only 2 GB to
> > play with instead of 3 GB, so attempting to mmap() a stack above
> > about 2 GB would cause pthread_create() to return EAGAIN.
> >
> 
> Yes this makes sense, however this call to pthread_create didn't specify
> any special addresses for the new thread. The pthread_create was called
> with the NULL attribute which means that the system defaults were being
> used. Something in the system has gone wrong...

I just glanced at the source in -STABLE, and it appears to be a
pthreads bug.  (Then again, maybe I'm missing something, since
nobody seems to have noticed this before.)  The default address at
which new thread stacks are created is just below the main stack.
This address is based on the lexical constant USRSTACK, but it
should be initialized in uthread_init() based on the kern.usrstack
value returned by sysctl.  (The correct value is already used to
map the main stack's red zone.)  The result is that you need to
make world and recompile any apps statically linked against
pthreads after building your new kernel in order to get things to
work.

I don't have time to fiddle with pthreads until after Christmas,
but you might see if the following patch (against -STABLE) helps
when you reduce the configured KVA size without remaking pthreads.

Index: uthread/uthread_init.c
===================================================================
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v
retrieving revision 1.23.2.10
diff -u -r1.23.2.10 uthread_init.c
--- uthread/uthread_init.c	2002/10/22 14:44:03	1.23.2.10
+++ uthread/uthread_init.c	2002/12/06 13:41:06
@@ -245,6 +245,8 @@
 		len = sizeof (int);
 		if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) == -1)
 			_usrstack = (void *)USRSTACK;
+		_next_stack = _usrstack - PTHREAD_STACK_INITIAL -
+		    PTHREAD_STACK_DEFAULT - (2 * PTHREAD_STACK_GUARD);
 		/*
 		 * Create a red zone below the main stack.  All other stacks are
 		 * constrained to a maximum size by the paramters passed to

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




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