From owner-freebsd-threads@FreeBSD.ORG Sun Aug 24 14:13:38 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 D58FB16A4C2 for ; Sun, 24 Aug 2003 14:13:38 -0700 (PDT) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B1C743F93 for ; Sun, 24 Aug 2003 14:13:34 -0700 (PDT) (envelope-from phantom@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h7P0LNsN092982 for ; Mon, 25 Aug 2003 00:21:24 GMT Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.2) id h7OLKdoQ025606; Mon, 25 Aug 2003 00:20:39 +0300 (EEST) (envelope-from phantom) Date: Mon, 25 Aug 2003 00:20:39 +0300 From: Alexey Zelkin To: threads@freebsd.org Message-ID: <20030825002039.A25487@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.7-STABLE i386 Subject: jdk14 & libc_r / fork() 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: Sun, 24 Aug 2003 21:13:39 -0000 hi, I have hit into a problem recently while trying to reproduce some deadlocks in jdk14 port. Problem details are simple -- JDK calls fork() and got frozen because of storm of unhandled (i.e. ignored SIGBUSes). I have checked that SIGBUS ignorance is not a problem, but reason of SIGBUS is. Some investigations shown that while doing of libc_r's wrapper for fork() we try to cleanup pthread's stacks. Since we are using custom stacks in JVM (malloc()'ed ones) libc_r attempts to free() them. Most times everything goes right, but sometimes (very rarely) SIGBUS is being generated while free()'ing of stacks. more details: it's RELENG_4 from trace (sorry, i accidiently deleted complete trace), but from memory can restore following points: libc_r/uthread/uthread_fork.c:154 -- [..] libc/stdlib/malloc.c:606 -- Any ideas on reasons ? PS: BTW, it's looks very similar to "red zone" violation in protection, but since problem appears after __sys_fork() call - it should not be a problem. Am I right ?