United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6570268 JDB: step002 fails assert(0 <= i && i < length(),"index out of bounds")
JDK-6570268 : JDB: step002 fails assert(0 <= i && i < length(),"index out of bounds")

Details
Type:
Bug
Submit Date:
2007-06-15
Status:
Closed
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
generic
Sub-Component:
runtime
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs11 (b01)

Related Reports
Backport:
Backport:
Backport:

Sub Tasks

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).
                                     
2007-06-19



Hardware and Software, Engineered to Work Together