> ArrayIndexOutOfBoundsException as following was hiding in
> ClhsdbPrintAll.java. See attached .jtr file in JBS.
>
> java.lang.ArrayIndexOutOfBoundsException: 7 6
> at
> jdk.hotspot.agent/sun.jvm.hotspot.oops.ResolvedMethodArray.getAt(ResolvedMethodArray.java:60)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPoolCache.getMethodEntryAt(ConstantPoolCache.java:99)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.interpreter.BytecodeWithCPIndex.indexForFieldOrMethod(BytecodeWithCPIndex.java:57)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.interpreter.BytecodeGetPut.toString(BytecodeGetPut.java:58)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator$1.visit(HTMLGenerator.java:685)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.interpreter.BytecodeDisassembler.decode(BytecodeDisassembler.java:156)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTML(HTMLGenerator.java:659)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$18$1.visit(CommandProcessor.java:876)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:113)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$18.doit(CommandProcessor.java:869)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2051)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2021)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1892)
> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:113)
> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:45)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:285)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>
>
> AFAICS all of failures are caused by `getfield` bytecode. We can see it in
> `javap`, but in SA, another bytecode values (e.g. "234") were detected. Thus
> `getfield` would not be handled as field operation at folloing code in
> BytecodeWithCPIndex.java, eventually the exception was thrown.
>
>
> if (cpCache == null) {
> return cpCacheIndex;
> } else if (code() == Bytecodes._invokedynamic) {
> return cpCache.getIndyEntryAt(cpCacheIndex).getConstantPoolIndex();
> } else if (Bytecodes.isFieldCode(code())) {
> return cpCache.getFieldEntryAt(cpCacheIndex).getConstantPoolIndex();
> } else {
> return cpCache.getMethodEntryAt(cpCacheInde...
Yasumasa Suenaga has updated the pull request incrementally with one additional
commit since the last revision:
Revert testcode changes
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/30808/files
- new: https://git.openjdk.org/jdk/pull/30808/files/89129cf3..a67f57d3
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=30808&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=30808&range=00-01
Stats: 12 lines in 3 files changed: 0 ins; 11 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/30808.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/30808/head:pull/30808
PR: https://git.openjdk.org/jdk/pull/30808
