On Sat, 18 Apr 2026 13:14:15 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();
> } else {
> return cpCache.getMethodEntryAt(cpCacheInde...
test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java line 157:
> 155: if (!allowStderrOutput) {
> 156: oa.stderrShouldBeEmptyIgnoreVMWarnings();
> 157: }
We need to be careful here. I think the reason for by default allowing stderr
output is because it can sometimes appear, but is not necessarily indicative of
bug. For example, sometimes during the stack dump an active thread can produce
an exception because it is not in a consistent state, but the thread we care
about (like SteadyStateThread) produces what we are looking for, so the test
should pass. I worry that this change is going to produce a lot of intermittent
failures.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30808#discussion_r3114397071
