Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5088035

hotswap fires assert(0 <= i && i < length(),"index out of bounds")

XMLWordPrintable

    • b26
    • generic
    • generic

        Name: dd4877 Date: 08/17/2004


        ###@###.### 2004-08-17

        This assertion fails in the following NSK tests:

            nsk/jvmti/scenarios/hotswap/HS101/hs101t004
            nsk/jvmti/scenarios/hotswap/HS101/hs101t006

        Here are the two analysis report entries:

        New JVMTI_QUICKLOOK failures (from 2004.08.03)
            nsk/jvmti/scenarios/hotswap/HS101/hs101t004
                This test failed on Solaris SPARC-64 and Solaris X86 Server VMs
                due to the following assertion failure:
                    Internal Error (src/share/vm/oops/cpCacheOop.hpp, 296)
                    assert(0 <= i && i < length(),"index out of bounds")
                                                                                        
                Update: I found the following two bugs with the same assert()
                    failure:
                        5065314 3/4 ShouldNotReachHere in xmlstream
                                    -XX:+PrintOptoAssembly -XX:CompileThreshold=2
                        5065316 3/4 Running with -XX:+CIPrintMethodCodes and
                                    -XX:CompileThreshold=2 crashes
                    I've pinged John Rose about the failure, but no response yet.
                Update: Here's John's response:
                    The assert will happen whenever a garbage constant pool
                    index is retrieved from the bytecode stream. This in turn
                    often happens because a methodOop is moved by the GC and
                    the interpreter keeps some sort of dangling pointer at the
                    old address. If you trace back in a core file, you might
                    find that the offending value of 'i' is two bytes out of
                    the middle of a pointer, or some other random thing.
                Update: based on John's response, I think we have a different bug
                    than the two I mentioned above.
                Update: This test has the following failure distribution from
                    2004.07.30 -> 2004.08.09:
                        1 ClientVM-comp-Solsparc
                        3 ClientVM-comp-solx86
                        3 ServerVM-comp-64BITLINUX-AMD64
                        4 ServerVM-comp-64BITSOLSPARC
                        1 ServerVM-comp-linux-i386
                        5 ServerVM-comp-solx86

        New JVMTI_QUICKLOOK failures (from 2004.08.16)
        * nsk/jvmti/scenarios/hotswap/HS101/hs101t006
                This test failed the following assertion on Solaris SPARC-64
                Server VM:
                    Internal Error (src/share/vm/oops/cpCacheOop.hpp, 296
                    Error: assert(0 <= i && i < length(),"index out of bounds")
                This is the same error that we see with hs101t004 (see below).



        ======================================================================

        This bug is also observed in the attached many.zip program which does not crash but gives incorrect results when run on "ntk" a Solaris Opteron box --

        98 WS_C - ntk: tests/redefmany] /java/re/jdk/1.5.0/promoted/fcs/b64/binaries/solaris-i586/bin/java
        -agentlib:test test
        encourageCompilation
        foo99
        encourageCompilation
        99 WS_C - ntk: tests/redefmany] /java/re/jdk/1.5.0/promoted/fcs/b64/binaries/solaris-i586/bin/java
        -agentlib:test test
        encourageCompilation
        foo99
        encourageCompilation
        Wrong value returned by static function 4, redefinition 1, cmd 1, expected 305419896, got 305419897
        Wrong value returned by static function 6, redefinition 1, cmd 1, expected 305419896, got 305419897
        100 WS_C - ntk: tests/redefmany] /java/re/jdk/1.5.0/promoted/fcs/b64/binaries/solaris-i586/bin/java -agentlib:test test
        encourageCompilation
        foo99
        encourageCompilation
        Wrong value returned by static function 0, redefinition 1, cmd 1, expected 305419896, got 305419898
        Wrong value returned by static function 4, redefinition 1, cmd 1, expected 305419896, got 305419897
        Wrong value returned by static function 5, redefinition 1, cmd 1, expected 305419896, got 305419897
        Wrong value returned by static function 6, redefinition 1, cmd 1, expected 305419896, got 305419897
        101 WS_C - ntk: tests/redefmany] /java/re/jdk/1.5.0/promoted/fcs/b64/binaries/solaris-i586/bin/java -agentlib:test test
        encourageCompilation
        foo99
        encourageCompilation
        Wrong value returned by static function 4, redefinition 1, cmd 1, expected 305419896, got 305419897
        Wrong value returned by static function 6, redefinition 1, cmd 1, expected 305419896, got 305419897
        102 WS_C - ntk: tests/redefmany] /java/re/jdk/1.5.0/promoted/fcs/b64/binaries/solaris-i586/bin/java -agentlib:test test
        encourageCompilation
        foo99
        encourageCompilation
        103 WS_C - ntk: tests/redefmany] /java/re/jdk/1.5.0/promoted/fcs/b64/binaries/solaris-i586/bin/java -agentlib:test test
        encourageCompilation
        foo99
        encourageCompilation
        Wrong value returned by static function 1, redefinition 1, cmd 1, expected 305419896, got 305419897
        Wrong value returned by static function 5, redefinition 1, cmd 1, expected 305419896, got 305419897
        Wrong value returned by static function 6, redefinition 1, cmd 1, expected 305419896, got 305419897

        -Robert
        ###@###.### 10/28/04 04:01 GMT

        This assertion failed in the gc_baseline nightly testing
        for

        nsk/jvmti/scenarios/hotswap/HS101/hs101t005

        on 02/20/2005 in the server, solx86, ParallelGC
        ###@###.### 2005-2-23 04:53:34 GMT

              dcubed Daniel Daugherty
              dcubed Daniel Daugherty
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: