8382485: ArrayIndexOutOfBoundsException was hiding in ClhsdbPrintAll.jtr by YaSuenag · Pull Request #30808 · openjdk/jdk

YaSuenag · 2026-04-18T13:14:15Z

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(cpCacheIndex).getConstantPoolIndex();
     }

In Bytecodes.java, following values should be handled as field operations. Bytecodes.isFieldCode() should identify them.

  public static final int _getstatic = 178; // 0xb2
  public static final int _putstatic = 179; // 0xb3
  public static final int _getfield = 180; // 0xb4
  public static final int _putfield = 181; // 0xb5

    :

  public static final int number_of_java_codes = 203;

  // JVM bytecodes
  public static final int _fast_agetfield = number_of_java_codes;
  public static final int _fast_bgetfield = 204;
  public static final int _fast_cgetfield = 205;
  public static final int _fast_dgetfield = 206;
  public static final int _fast_fgetfield = 207;
  public static final int _fast_igetfield = 208;
  public static final int _fast_lgetfield = 209;
  public static final int _fast_sgetfield = 210;
  public static final int _fast_aputfield = 211;
  public static final int _fast_bputfield = 212;
  public static final int _fast_zputfield = 213;
  public static final int _fast_cputfield = 214;
  public static final int _fast_dputfield = 215;
  public static final int _fast_fputfield = 216;
  public static final int _fast_iputfield = 217;
  public static final int _fast_lputfield = 218;
  public static final int _fast_sputfield = 219;

    :

  // Bytecodes rewritten at CDS dump time
  public static final int _nofast_getfield = 234;
  public static final int _nofast_putfield = 235;

Maybe this is long-standing bug because the exception could not be caught jtreg tests, thus I updated testcase to check stderr. But ClhsdbDumpheap.java and ClhsdbJhisto.java would ignore this because they prints message into stderr or checks strings in stderr.

I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8382485: ArrayIndexOutOfBoundsException was hiding in ClhsdbPrintAll.jtr (Bug - P4)

Reviewers

Chris Plummer (@plummercj - Reviewer)
Kevin Walls (@kevinjwalls - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/30808/head:pull/30808
$ git checkout pull/30808

Update a local copy of the PR:
$ git checkout pull/30808
$ git pull https://git.openjdk.org/jdk.git pull/30808/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 30808

View PR using the GUI difftool:
$ git pr show -t 30808

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/30808.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2026-04-18T13:15:33Z

👋 Welcome back ysuenaga! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2026-04-18T13:17:01Z

@YaSuenag This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8382485: ArrayIndexOutOfBoundsException was hiding in ClhsdbPrintAll.jtr

Reviewed-by: cjplummer, kevinw

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 110 new commits pushed to the master branch:

7aa7f28: 8381811: [S390] Add support for JDK-8200555
d32eb4b: 8376300: Avoid more leaks in KeystoreImpl.m because of missing CFRelease calls
a0caf2c: 8383163: Build without CDS broken after 8382170
... and 107 more: https://git.openjdk.org/jdk/compare/0dd0108c1a7b3658df536adbc2bd68fa5167539d...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2026-04-18T13:17:38Z

@YaSuenag The following label will be automatically applied to this pull request:

serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2026-04-18T13:21:08Z

Webrevs

01: Full - Incremental (a67f57d3)
00: Full (89129cf3)

YaSuenag · 2026-04-19T08:41:43Z

Changes in ClhsdbLauncher.java‎ causes new error in mixed jstack tests on Alpine, but it would be fixed in #30815.

plummercj · 2026-04-21T00:39:18Z

+        if (!allowStderrOutput) {
+            oa.stderrShouldBeEmptyIgnoreVMWarnings();
+        }


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?

But that is what my concern is. We can see exceptions on stderr that we want to ignore.

Understood, so should I remove changes for the test from PR? I think it is difficult to choose exceptions/errors what we can ignore.

I reverted changes for testcode. I think it is reasonable so far.
@plummercj Can you review?

plummercj

Looks good. Thanks for the fix!

YaSuenag · 2026-04-24T14:17:52Z

/integrate

openjdk · 2026-04-24T14:19:03Z

Going to push as commit df8a940.
Since your change was applied there have been 117 commits pushed to the master branch:

5596e81: 8381975: CPU feature verification in AOTCodeCache should check for exact match
71e5a16: 8381651: Remove non-failing ModalFocusTransfer test from Problemlist
cd01fab: 8382614: Consolidate implementation of current_stack_base_and_size on BSD
... and 114 more: https://git.openjdk.org/jdk/compare/0dd0108c1a7b3658df536adbc2bd68fa5167539d...master

Your commit was automatically rebased without conflicts.

openjdk · 2026-04-24T14:19:15Z

@YaSuenag Pushed as commit df8a940.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8382485: ArrayIndexOutOfBoundsException was hiding in ClhsdbPrintAll.jtr

89129cf

openjdk Bot added the serviceability serviceability-dev@openjdk.org label Apr 18, 2026

openjdk Bot added the rfr Pull request is ready for review label Apr 18, 2026

plummercj reviewed Apr 21, 2026

View reviewed changes

Revert testcode changes

a67f57d

plummercj approved these changes Apr 24, 2026

View reviewed changes

openjdk Bot added the ready Pull request is ready to be integrated label Apr 24, 2026

kevinjwalls approved these changes Apr 24, 2026

View reviewed changes

openjdk Bot added the integrated Pull request has been integrated label Apr 24, 2026

openjdk Bot closed this Apr 24, 2026

openjdk Bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Apr 24, 2026

YaSuenag deleted the JDK-8382485 branch April 25, 2026 01:13

Conversation

YaSuenag commented Apr 18, 2026 • edited by openjdk Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper Bot commented Apr 18, 2026

Uh oh!

openjdk Bot commented Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk Bot commented Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge Bot commented Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

YaSuenag commented Apr 19, 2026

Uh oh!

plummercj Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

YaSuenag Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

plummercj Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

YaSuenag Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

YaSuenag Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

plummercj left a comment

Choose a reason for hiding this comment

Uh oh!

YaSuenag commented Apr 24, 2026

Uh oh!

openjdk Bot commented Apr 24, 2026

Uh oh!

openjdk Bot commented Apr 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

YaSuenag commented Apr 18, 2026 •

edited by openjdk Bot

Loading

openjdk Bot commented Apr 18, 2026 •

edited

Loading

openjdk Bot commented Apr 18, 2026 •

edited

Loading

mlbridge Bot commented Apr 18, 2026 •

edited

Loading