From owner-freebsd-threads@FreeBSD.ORG Wed Oct 22 23:34:48 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8AA916A4B3 for ; Wed, 22 Oct 2003 23:34:48 -0700 (PDT) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAD0E43FCB for ; Wed, 22 Oct 2003 23:34:46 -0700 (PDT) (envelope-from phantom@FreeBSD.org.ua) Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.6) id h9N6hxjr074674; Thu, 23 Oct 2003 09:43:59 +0300 (EEST) (envelope-from phantom) From: Alexey Zelkin To: Daniel Eischen Message-ID: <20031023094359.A74499@phantom.cris.net> References: <20031023010038.A71141@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Wed, Oct 22, 2003 at 10:06:10PM -0400 X-Operating-System: FreeBSD 4.7-STABLE i386 cc: threads@freebsd.org Subject: Re: libc_r & direct usage of syscalls X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 23 Oct 2003 06:34:48 -0000 X-Original-Date: Thu, 23 Oct 2003 09:43:59 +0300 X-List-Received-Date: Thu, 23 Oct 2003 06:34:48 -0000 hi, On Wed, Oct 22, 2003 at 10:06:10PM -0400, Daniel Eischen wrote: > > Some of you may remember a story about strange problems I had > > with native jdk14 and fork() calls. > > > > In few words -- sometimes, in absolutely random order JVM just after > > call to fork() function become unusable due to SIGBUS signal storm > > (JVM signal handler decided that this signal is not fatal and did not > > stop an application). > > > > Today I have completely tracked it down. Or correctly to say > > got a 100% reproducible .java testcase and wrote few more .c testcases in > > order to prove my point of view. > > > > JVM is using internally usual stack protection logic. Every two pages on > > borders of stack are protected with mmap(). When something accesses > > it SIGBUS is generated and signal handler forces overflowing thread > > to rollback some operation until it may safely continue its job. > > > > fork() is special case here. When fork() is called, child process > > is need to reinitialize a libc_r internal state (this job is done by > > fork() wrapper located in libc_r/uthread/uthread_fork.c). One of steps > > of reinitialization process is free()'ing of pthreads stacks. Caveat here > > is unchanged protections on stack pages. Right after some stacks are > > free()'ed, malloc internal (struct pginfo *) info got allocated into > > protected region and this info being changed we get a big *KABOOM* (i.e. > > SIGBUS). > > Here's what POSIX has to say about fork() and threaded processes: > > A process shall be created with a single thread. If a multi-threaded > process calls fork(), the new process shall contain a replica of the > calling thread and its entire address space, possibly including the > states of mutexes and other resources. Consequently, to avoid > errors, the child process may only execute async-signal-safe > operations until such time as one of the exec functions is called. > [THR] Fork handlers may be established by means of the > pthread_atfork() function in order to maintain application > invariants across fork() calls. > > When the application calls fork() from a signal handler and any of > the fork handlers registered by pthread_atfork() calls a function > that is not asynch-signal-safe, the behavior is undefined. >From quick look I was unable to find any entity named pthread_atfork() in FreeBSD. I also doubt it will help with my issue at all, because most probabaly atfork functions will be executed at the end of pthread_fork(), but my problem appears at the begining of the function. > Libkse currently doesn't do any reinitialization of internal library > state (libc _or_ libkse) on a fork(). You cannot rely on libc > state (malloc state, e.g.) or libkse state after a fork(). Well. I looked on fork() implementation in libkse and it looks safe for my case. Is there any standard way to detect which library I am running ? I can do runtime check (using dl*() funcs) in order to understand which library application running and execute different code paths. > For what purpose is fork() being used by the JVM? For spawning another process. As I shown in code examples in previous letter fork() is used to born another process, then close unused file descriptors in child and then call execvp().