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-hackers" 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>