JDK-6570268 : JDB: step002 fails assert(0 <= i && i < length(),"index out of bounds")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-06-15
  • Updated: 2012-02-01
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6Resolved 7Fixed hs11Fixed
Description
New nsk.jdb failures (from 2007.06.14)
*   nsk/jdb/step/step002
        This test failed the following assertion (in jdb.session log):

            Internal Error (src/share/vm/oops/cpCacheOop.hpp:315)
            Error: assert(0 <= i && i < length(),"index out of bounds")

        on Linux AMD64 Server VM (machine vm-amd64-01), Solaris AMD64
        Server VM (machine vm-x86-1), Solaris SPARC-64 Server VM
        (machine vm-ultra80-01), Linux IA32 Client VM (machine
        jck-win1), Linux IA32 Server VM (machine jck-win1), Solaris
        SPARC Client VM (machine nanonano), Solaris SPARC Server VM
        (machine nyny), Solaris X86 Client VM (machine mspacman), and
        Solaris X86 Server VM (machine speedbump),

        Viswadeep's search tool for 2007.06.01 -> latest shows that
        this failure mode occurs in c2_baseline, rt_baseline, and
        service_hs_baseline. The first failure occurs in rt_baseline
        on 2007.06.06 using 20070605173931.km88527.6559877-fastdebug.
        Keith's job fixed:

            6559877 3/3 Class Validator Abort Denial of Service
            6559858 3/3 Class Validator strlen() Denial of Service

        Update: I did a search in Bugster for nsk/jdb/step/step002 and
            didn't find an existing bug.
Comments
EVALUATION The fix for 6559877 inadvertantly touched the code path used by generateOopMap. This particular test causes the generateOopMap code to see a breakpoint and not properly resolve the replaced bytecode, which leads to later bytecode parsing errors. To fix this, we need to separate the code paths needed for 6559877 (which requires no attempt at breakpoint resolution) and for generateOopsMaps (which requires the original bytecode).
19-06-2007