On Thu, 23 Apr 2026 05:42:07 GMT, Yasumasa Suenaga <[email protected]> wrote:
>> 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();
>>...
>
> Yasumasa Suenaga has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Revert testcode changes
Looks good. Thanks for the fix!
-------------
Marked as reviewed by cjplummer (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/30808#pullrequestreview-4167730032
