From owner-freebsd-hackers Fri Dec 6 6:40:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C2A537B401; Fri, 6 Dec 2002 06:40:55 -0800 (PST) Received: from apache.metrocom.ru (www.metrocom.ru [195.5.128.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id C98C443ED1; Fri, 6 Dec 2002 06:40:52 -0800 (PST) (envelope-from alex@metrocom.ru) Received: from apache.metrocom.ru (localhost [127.0.0.1]) by apache.metrocom.ru (8.12.6/8.12.6) with ESMTP id gB6EeltQ004783; Fri, 6 Dec 2002 17:40:48 +0300 (MSK) Received: from localhost (alex@localhost) by apache.metrocom.ru (8.12.6/8.12.6/Submit) with ESMTP id gB6Eelc5004780; Fri, 6 Dec 2002 17:40:47 +0300 (MSK) X-Authentication-Warning: apache.metrocom.ru: alex owned process doing -bs Date: Fri, 6 Dec 2002 17:40:46 +0300 (MSK) From: Varshavchick Alexander To: David Schultz Cc: Terry Lambert , , Subject: Re: maxusers and random system freezes In-Reply-To: <20021206134724.GA16965@HAL9000.homeunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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