Date: Mon, 3 Mar 2003 23:59:00 -0500 From: Christopher Rued <c.rued@xsb.com> To: Greg Lewis <glewis@eyesbeyond.com> Cc: Christopher Rued <c.rued@xsb.com>, Munehiro Matsuda <haro@h4.dion.ne.jp>, freebsd-java@FreeBSD.ORG Subject: Re: [REPOST] java/47397: [PATCH] java/jdk13 to enable HotSpot Message-ID: <15972.12948.691253.826369@ool-18bacefa.dyn.optonline.net> In-Reply-To: <20030227161330.A58544@misty.eyesbeyond.com> References: <15962.16668.753657.116140@ool-18bacefa.dyn.optonline.net> <20030225.014627.41626713.haro@h4.dion.ne.jp> <20030225154141.A48569@misty.eyesbeyond.com> <20030225.225404.74756090.haro@h4.dion.ne.jp> <20030225182018.GA62141@misty.eyesbeyond.com> <20030226050459.A51511@misty.eyesbeyond.com> <15965.32312.772849.720730@ool-18bacefa.dyn.optonline.net> <20030227161330.A58544@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Java(TM) 2 Runtime Environment, Standard Edition (build > > 1.3.1-p8-cbr-030226-09:3 > > 5) > > Java HotSpot(TM) Client VM (build 1.3.1-internal, mixed mode) > > Unexpected Signal : 4 occurred at PC=0x80c2427 > > Function name=(N/A) > > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > > just occurred. Please refer to release documentation for > > possible > > reason and solutions. > > Current Java thread: > > Error: Cannot print dynamic libraries. Function not implemented for > > FreeBSD > > Local Time = Wed Feb 26 21:46:31 2003 > > Elapsed Time = -2147483648 > > # > > # HotSpot Virtual Machine Error : 4 > > # Error ID : 4F530E43505002CC > > # Please report this error at > > # http://java.sun.com/cgi-bin/bugreport.cgi > > # > > # Java VM: Java HotSpot(TM) Client VM (1.3.1-internal mixed mode) > > # > > # An error report file has been saved as hs_err_pid56235.log. > > # Please refer to the file for further information. > > # > > Abort (core dumped) > > > > FYI: > > I'm running 4.7-STABLE FreeBSD 4.7-STABLE #1: Sat Feb 8 19:58:28 > > EST 2003, cvsupped earlier that day. The processor is a 500 MHz > > AMD K6-II. > > Thats about the same date as my userland. I've more recently updated > the kernel, but the differences aren't great. Needless to say, it > works for me (or I wouldn't have posted the patch :). The best I can > suggest is to pull out gdb and try and get some more information about > what is going on. Okay -- from this backtrace: #0 0x080edafb in ?? () #1 0x286613fd in StubRoutines::_code1 () from /usr/local/jdk1.3.1/jre/lib/i386/client/libjvm_g.so #2 0x282a739f in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /usr/local/jdk1.3.1/jre/lib/i386/client/libjvm_g.so #3 0x282a6eb4 in JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) () from /usr/local/jdk1.3.1/jre/lib/i386/client/libjvm_g.so #4 0x282a6bce in JavaCalls::call_static(JavaValue*, KlassHandle, symbolHandle, symbolHandle, JavaCallArguments*, Thread*) () from /usr/local/jdk1.3.1/jre/lib/i386/client/libjvm_g.so #5 0x282a6c32 in JavaCalls::call_static(JavaValue*, KlassHandle, symbolHandle, symbolHandle, Thread*) () from /usr/local/jdk1.3.1/jre/lib/i386/client/libjvm_g.so #6 0x283e4686 in JavaThread::exit(long) () from /usr/local/jdk1.3.1/jre/lib/i386/client/libjvm_g.so #7 0x283e8f31 in Threads::destroy_vm() () from /usr/local/jdk1.3.1/jre/lib/i386/client/libjvm_g.so #8 0x282dfe23 in jni_DestroyJavaVM () from /usr/local/jdk1.3.1/jre/lib/i386/client/libjvm_g.so #9 0x080493d6 in main (argc=0, argv=0xbfbff8d4) at ../../../../src/share/bin/java.c:346 #10 0x08048bc2 in _start () I was able to determine (I think) that the crash was occurring at some point in the shutdown method in java.lang.Shutdown. Inserting debugging printout and recompiling led me to the line below that has "synchronized(Shutdown.class)". synchronized (lock) { switch (state) { case RUNNING: /* Initiate shutdown */ state = HOOKS; break; case HOOKS: /* Stall and then return */ case FINALIZERS: break; } } synchronized (Shutdown.class) { sequence(); } So, it looks like it was failing when it attempted to get a lock on the class -- I was curious, so I tried the following: synchronized (Shutdown.class) { System.out.println("Just checking..."); } synchronized (lock) { switch (state) { case RUNNING: /* Initiate shutdown */ state = HOOKS; break; case HOOKS: /* Stall and then return */ case FINALIZERS: break; } } synchronized (Shutdown.class) { sequence(); } And now it seems to crash when attempted to acquire a lock on "lock". I've attempted several different sequences of synchronizing on the two, and also went so far as to add Thread.sleeps to try to make sure what I'm seeing isn't just a matter of timing. Regardless of the order of the synchronized blocks, it always seems to fail just before the second synchronized block executes -- which makes me think that something is wrong with the locks (or "monitors"). That doesn't really explain why it doesn't work for me, but seems to work for everyone else, but that's what I've been observing so far. Does anyone else have this working on the same hardware I have (AMD K6-II 500 MHz processor)? Thanks. --Chris 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?15972.12948.691253.826369>