Date: Tue, 26 Feb 2002 12:15:10 -0800 From: Bill Huey <billh@gnuppy.monkey.org> To: Stacy Millions <stacy@millions.ca> Cc: "FreeBSD Java mailing list (E-mail)" <freebsd-java@FreeBSD.ORG> Subject: Re: 1.3.1p6 dies sigbus with threads Message-ID: <20020226201510.GA2572@gnuppy.monkey.org> In-Reply-To: <3C7BDF7E.D8645D7@millions.ca> References: <59063B5B4D98D311BC0D0001FA7E452205FDA3A4@l04.research.kpn.com> <3C7BDF7E.D8645D7@millions.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020226201510.GA2572>