From owner-freebsd-java Tue Feb 26 12:15:35 2002 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by hub.freebsd.org (Postfix) with ESMTP id 0CB3437B405 for ; Tue, 26 Feb 2002 12:15:28 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.34 #1 (Debian)) id 16fo0E-0000hN-00; Tue, 26 Feb 2002 12:15:10 -0800 Date: Tue, 26 Feb 2002 12:15:10 -0800 To: Stacy Millions Cc: "FreeBSD Java mailing list (E-mail)" Subject: Re: 1.3.1p6 dies sigbus with threads Message-ID: <20020226201510.GA2572@gnuppy.monkey.org> References: <59063B5B4D98D311BC0D0001FA7E452205FDA3A4@l04.research.kpn.com> <3C7BDF7E.D8645D7@millions.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C7BDF7E.D8645D7@millions.ca> User-Agent: Mutt/1.3.27i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Feb 26, 2002 at 12:18:22PM -0700, Stacy Millions wrote: > Another data point, I have a simple test program that has the same > result (as my kids would say, "java goes 'trip, thud'") just by using > SecureRandom (who fires of a whole load of threads). You have to > run it about 50 times, but eventually it will dump core. I made > it a Swing app to get the additional AWT and friends threads to help > speed up the "trip, thud" process. > > The problem existed in p5 as well (actually, I think it happens less > often in p6, but I don't have any hard data to back that up). > Unfortunately, I have not had time to debug it farther. Hmmm, an assertion blew. > SIGABRT 6* abort (generated by abort(3) routine) ... > #0 0x280b6994 in kill () from /usr/lib/libc.so.4 > #1 0x280f2b35 in abort () from /usr/lib/libc.so.4 > #2 0x28160ad9 in Abort () from /usr/local/jdk1.3.1/jre/lib/i386/classic/libjvm.so > #3 0x28189a9f in panicHandler () from /usr/local/jdk1.3.1/jre/lib/i386/classic/libjvm.so > #4 0x28076647 in userSignalHandler () from /usr/local/jdk1.3.1/jre/lib/i386/green_threads/libhpi.so > #5 0x28076600 in intrDispatch () from /usr/local/jdk1.3.1/jre/lib/i386/green_threads/libhpi.so > #6 0x2806f917 in intrDispatchMD () from /usr/local/jdk1.3.1/jre/lib/i386/green_threads/libhpi.so > #7 0xbfbfffac in ?? () > #8 0x28073c5d in reschedule () from /usr/local/jdk1.3.1/jre/lib/i386/green_threads/libhpi.so > #9 0x28073500 in queueWait () from /usr/local/jdk1.3.1/jre/lib/i386/green_threads/libhpi.so > #10 0x28073ac9 in sysMonitorWait () from /usr/local/jdk1.3.1/jre/lib/i386/green_threads/libhpi.so > #11 0x28071f3b in poll () from /usr/local/jdk1.3.1/jre/lib/i386/green_threads/libhpi.so > #12 0x2dff6879 in performPoll () from /usr/local/jdk1.3.1/jre/lib/i386/libawt.so > #13 0x2dff677f in waitForEvents () from /usr/local/jdk1.3.1/jre/lib/i386/libawt.so > #14 0x2dff6482 in awt_MToolkit_loop () from /usr/local/jdk1.3.1/jre/lib/i386/libawt.so > #15 0x2dff7339 in Java_sun_awt_motif_MToolkit_run () from /usr/local/jdk1.3.1/jre/lib/i386/libawt.so > #16 0x28160bd0 in invoke_V_V () from /usr/local/jdk1.3.1/jre/lib/i386/classic/libjvm.so > #17 0x281586c0 in invokeLazyNativeMethod () from /usr/local/jdk1.3.1/jre/lib/i386/classic/libjvm.so > #18 0x28191766 in found_it6 () from /usr/local/jdk1.3.1/jre/lib/i386/classic/libjvm.so That's unusual. It's a different stack trace than Jees's. Another thing that's important is if it is consistently blowing it in the same place or not. If it is then it's likely a problem with the basic subsystem some how, if not then it's generally a threading problem. I can't tell at this point without more information, but these are important bugs to squash and shouldn't be blown off by the core JVM staff. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message