Date: Fri, 6 Dec 2002 17:40:46 +0300 (MSK) From: Varshavchick Alexander <alex@metrocom.ru> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: Terry Lambert <tlambert2@mindspring.com>, <freebsd-questions@FreeBSD.ORG>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: maxusers and random system freezes Message-ID: <Pine.GSO.4.33.0212061719220.15512-100000@apache.metrocom.ru> In-Reply-To: <20021206134724.GA16965@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Dec 2002, David Schultz wrote: ... > > 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. > ... The patch which you've suggested seems to be logical enough, yet I too cannot understand why nobody got stuck into this thing before. It means that no one in the world ever changed KVA space and used pthreads then, however real life can often be more rich than we think about it. Thank you alot, now I can estimate how this issue can influence the server, there can be nothing worse than some unknown thing which you know is living and messing things up. Now I know which software can be victim to it and what can be considered to be safe. I don't have much opportunity of fiddling with this production server, but if this issue arise again your patch will be handy. BTW will you not be sending it as a bug report with a patch already ready? ---- Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) 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?Pine.GSO.4.33.0212061719220.15512-100000>