It is currently Sun, 18 Nov 2018 03:08:40 GMT



 
Author Message
 java/47397: [PATCH] java/jdk13 to enable HotSpot

 > >     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://www.**-**.com/
 > >     #
 > >     # 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 majord...@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message



 Sat, 20 Aug 2005 12:59:17 GMT   
 
   [ 1 post ] 

Similar Threads

1. java/47397: [PATCH] java/jdk13 to enable HotSpot

2. java/47397: [PATCH] java/jdk13 to enable HotSpot compilation

3. java/47397: [PATCH] java/jdk13 to enable HotSpot compilation

4. Java, Java, Java, Java, Java, Java .....

5. Java with HotSpot on FreeBSD (Was: Re: A Call to Action for freebsd-java)

6. bsd.java.mk and XML/XSLT Re: java/jdk13 does not autodetect itself

7. java/48164: ports/java/jdk13: won't compile

8. java/42595: java/jdk13: Math.pow function from appletviewer

9. java/41645: Port jdk13 with patch level 7 does not compile

10. java/41646: Port jdk13 with patch level 7 does not compile


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software