On Tue, 21 Apr 2026 00:39:18 GMT, Chris Plummer <[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();
>>...
>
> 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.
Indeed the thread might have inconsistent state because they would be stopped
by signal or `ptrace()`.
So is it better to check `*Exception: ` and `*Error: ` in stderr?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30808#discussion_r3115193636
