From owner-freebsd-bugs Tue Oct 16 11: 0: 9 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 65E1437B40D for ; Tue, 16 Oct 2001 11:00:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f9GI03w02210; Tue, 16 Oct 2001 11:00:03 -0700 (PDT) (envelope-from gnats) Date: Tue, 16 Oct 2001 11:00:03 -0700 (PDT) Message-Id: <200110161800.f9GI03w02210@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Jason Evans Subject: Re: kern/31310: pthread broken with KVA_PAGES=512 Reply-To: Jason Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/31310; it has been noted by GNATS. From: Jason Evans To: "justin@skysoft.com.tw" Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/31310: pthread broken with KVA_PAGES=512 Date: Tue, 16 Oct 2001 11:01:39 -0700 On Tue, Oct 16, 2001 at 04:16:51PM +0800, justin@skysoft.com.tw wrote: > > >Description: > KVA_PAGES in kernel config is set to 512, and I had 'make world' > to update /usr/lib. > > When I run any program that use pthread (linked with libc_r), > it prints: > > > Fatal error 'Cannot allocate red zone for initial thread' at line ? in file > /usr/src/lib/libc_r/uthread/uthread_init.c (errno = ?) > > Abort trap (core dumped) > > > I didn't have this problem on 4.4-RC0 with ldscript.i386 and pmap.h > patched as the following to enlarge kernel address space to 2G. I'm not sure I understand what you're doing, so let me try to summarize my understanding before guessing what the problem is. It sounds like you are changing the amount of address space reserved for the kernel, which affects where the userland stack is mapped. Look in src/lib/libc_r/uthread/uthread_init.c for the mmap() call that creates the red zone: /* * Create a red zone below the main stack. All other stacks are * constrained to a maximum size by the paramters passed to * mmap(), but this stack is only limited by resource limits, so * this stack needs an explicitly mapped red zone to protect the * thread stack that is just beyond. */ if (mmap((void *) USRSTACK - PTHREAD_STACK_INITIAL - PTHREAD_STACK_GUARD, PTHREAD_STACK_GUARD, 0, MAP_ANON, -1, 0) == MAP_FAILED) PANIC("Cannot allocate red zone for initial thread"); The code depends on the USRSTACK macro when determining where to create the red zone, and I suspect that its value is somewhere in kernel memory in your case. From src/sys/i386/include/vmparam.h: #define VM_MAXUSER_ADDRESS VADDR(UMAXPTDI, UMAXPTEOFF) #define USRSTACK VM_MAXUSER_ADDRESS Please let me know if after further diagnostic effort you discover this to be an actual problem in libc_r. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message