Date: Tue, 26 Feb 2002 10:57:27 -0800 From: Bill Huey <billh@gnuppy.monkey.org> To: "Koster, K.J." <K.J.Koster@kpn.com> Cc: "FreeBSD Java mailing list (E-mail)" <freebsd-java@freebsd.org> Subject: Re: 1.3.1p6 dies sigbus with threads Message-ID: <20020226185727.GA1920@gnuppy.monkey.org> In-Reply-To: <59063B5B4D98D311BC0D0001FA7E452205FDA3A4@l04.research.kpn.com> References: <59063B5B4D98D311BC0D0001FA7E452205FDA3A4@l04.research.kpn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 26, 2002 at 07:32:24PM +0100, Koster, K.J. wrote: > Dear All, and Bill Huey in particular, :) > > I can make 1.3.1p6 fall onto it's face by creating threads and having them > generate HTTP traffic against a local web server (HTTPUnit against an Orion > server). The code works fine on a FreeBSD machine with Linux-jdk13 and on > the massive Sun that will be our production server. > > #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 0x2815a7d5 in cacheAlloc () from > /usr/local/jdk1.3.1/jre/lib/i386/classic/libjvm.so > #9 0x2815abe9 in allocArray () from > /usr/local/jdk1.3.1/jre/lib/i386/classic/libjvm.so > #10 0x28190e4f in N1_newarray6 () from > /usr/local/jdk1.3.1/jre/lib/i386/classic/libjvm.so > #11 0x28e7c7e8 in ?? () > #12 0x8052400 in ?? () > #13 0x0 in ?? () > (gdb) Hmmm, looks like an allocation problem from the stack trace and then throwing a signal from a possible SEGV. > I would appreciate suggestions on how to debug this in more detail. > > How can I enable additional debugging code that can help track this bug > down? What I do is attach GDB with symbol references to an already running JVM process and then work things from there. Move into the directory and invoke gdb to get the symbols or something like that. I'm not sure how this is going to help you out though. Let me think. Hmmm, try seeing if you can turn on the GC and memory allocation debug stuff in the source code and then try it again. Allocations will run quite a bit slower, but it might give you more debugging output assuming that it's hitting this logic. Try that first and come back. If that's not it, then it'll require a more dedicated effort possibly from me to get at it since their's a lot that can go on inside the JVM. It's definitely a tough one. Maybe Fuyuhiko might have some input. 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?20020226185727.GA1920>