From owner-freebsd-threads@FreeBSD.ORG Mon Jan 26 11:03:45 2004 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 D2FEE16A4CE for ; Mon, 26 Jan 2004 11:03:45 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 485FF43D60 for ; Mon, 26 Jan 2004 11:02:07 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i0QJ1lFR038142 for ; Mon, 26 Jan 2004 11:01:47 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i0QJ1kAU038135 for freebsd-threads@freebsd.org; Mon, 26 Jan 2004 11:01:46 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 26 Jan 2004 11:01:46 -0800 (PST) Message-Id: <200401261901.i0QJ1kAU038135@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you 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: , X-List-Received-Date: Mon, 26 Jan 2004 19:03:46 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2002/01/16] kern/33951 threads pthread_cancel is ignored 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/19] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2001/04/02] bin/26307 threads libc_r aborts when using the KDE media pl o [2001/10/31] bin/31661 threads pthread_kill signal handler doesn't get s o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/03/07] bin/35622 threads sigaltstack is missing in libc_r o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] bin/39922 threads [PATCH?] Threaded applications executed w o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag o [2002/10/10] kern/43887 threads abnormal CPU useage when use pthread_mute o [2003/03/02] bin/48856 threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] bin/49087 threads Signals lost in programs linked with libc a [2003/04/08] bin/50733 threads buildworld won't build, because of linkin o [2003/05/07] bin/51949 threads thread in accept cannot be cancelled o [2003/05/30] kern/52817 threads top(1) shows garbage for threaded process 19 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/25] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] bin/30464 threads pthread mutex attributes -- pshared o [2002/05/02] bin/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwri o [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. 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(). From owner-freebsd-threads@FreeBSD.ORG Thu Oct 23 02:35:04 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 2873216A4B3 for ; Thu, 23 Oct 2003 02:35:04 -0700 (PDT) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E34343F93 for ; Thu, 23 Oct 2003 02:35:00 -0700 (PDT) (envelope-from phantom@FreeBSD.org.ua) Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.6) id h9N9i7t6075871; Thu, 23 Oct 2003 12:44:07 +0300 (EEST) (envelope-from phantom) From: Alexey Zelkin To: Daniel Eischen Message-ID: <20031023124407.A75834@phantom.cris.net> References: <20031023010038.A71141@phantom.cris.net> <20031023094359.A74499@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: <20031023094359.A74499@phantom.cris.net>; from phantom@FreeBSD.org.ua on Thu, Oct 23, 2003 at 09:43:59AM +0300 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 09:35:04 -0000 X-Original-Date: Thu, 23 Oct 2003 12:44:07 +0300 X-List-Received-Date: Thu, 23 Oct 2003 09:35:04 -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().