8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5

[jyukutyo]

A crash occurs when running with -Xshare:dump and specifying a class list file generated by an older JDK (e.g. JDK 17) via -XX:SharedClassListFile.
This pull request fixes the issue and prevents the crash.

Details

Example command to reproduce:

$ ./jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld              
#                                                                                                                                                              
# A fatal error has been detected by the Java Runtime Environment:                                                                                             
#                                                                                                                                                              
#  SIGSEGV (0xb) at pc=0x0000ffff8610355c, pid=53155, tid=53156                                                                                                
#                                                                                                                                                              
# JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.jyukutyo.jyukutyo-jdk)                                                    
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.jyukutyo.jyukutyo-jdk, interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux-
aarch64)                                                                                                                                                       
# Problematic frame:                                                                                                                                           
# V  [libjvm.so+0x90355c]  ClassListParser::resolve_indy_impl(Symbol*, JavaThread*)+0x2dc 
[full crash log omitted for brevity]

The class list file that triggers the problem, generated by JDK 17, looks like this:

@lambda-proxy java/lang/System$LoggerFinder run ()Ljava/security/PrivilegedAction; ()Ljava/lang/Object; REF_invokeStatic java/lang/System$LoggerFinder lambda$accessProvider$0 ()Ljava/lang/System$LoggerFinder; ()Ljava/lang/System$LoggerFinder;

In contrast, the recent JDK generates class list contents as follows:

@cp jdk/internal/logger/LoggerFinderLoader 15 21 30 96 99 105 110 117 118 122 141
@cp jdk/internal/logger/DefaultLoggerFinder 1 2 7 8 14 22 29 30
@cp java/lang/System$LoggerFinder 1 2 10 27 31

When an old-style class list file is used, the _resolved_indy_entries variable remains null, which leads to a crash during -Xshare:dump.
This PR adds a null check to avoid the crash.
After applying this fix, running with the same options no longer results in a crash. Instead, a warning is shown as expected:

$ ./jdk-26_fixed/jdk-26/fastdebug/bin/java -Xshare:dump -XX:SharedClassListFile=classes.list -XX:SharedArchiveFile=noop.jsa HelloWorld
[0.094s][warning][cds] No invoke dynamic constant pool entry can be found for class java/lang/System$LoggerFinder. The classlist is probably out-of-date.

Additional note

We may also want to apply the same fix to the resolved_indy_entry_at function in the ConstantPoolCache class. Please let me know if that is desirable.
For reference, the current implementation is:

inline ResolvedIndyEntry* ConstantPoolCache::resolved_indy_entry_at(int index) const {
  return _resolved_indy_entries->adr_at(index);
}

---

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-8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5 (Bug - P3)

Reviewers

• Coleen Phillimore (@coleenp - Reviewer)
• Matias Saavedra Silva (@matias9927 - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26770

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back ksakata! 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]

@jyukutyo 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:

8356324: JVM crash (SIGSEGV at ClassListParser::resolve_indy_impl) during -Xshare:dump starting from 21.0.5

Reviewed-by: coleenp, matsaave

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 62 new commits pushed to the master branch:

• 3bbaa77: 8364320: String encodeUTF8 latin1 with negatives
• 0858743: 8277585: Remove the terminally deprecated finalize() method from javax.imageio.stream APIs
• 884076f: 8365719: Refactor uses of JLA.uncheckedNewStringNoRepl
• ... and 59 more: https://git.openjdk.org/jdk/compare/9c266ae83c047025d778da41e413701ac3b50b03...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]

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

• hotspot

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]

Webrevs

• 00: Full (d26d191c)

[shipilev]

Have you figured out why it started crashing with 21.0.5? I.e. what was the change that triggered it?

[jyukutyo]

Thank you for your question. I tried to identify the change that caused the crash by comparing 21.0.4 and 21.0.5, but I wasn't able to pinpoint it with my initial check.
I'll take another look and let you know if I find the specific commit or change that triggered the issue.

[coleenp]

This looks good. I think resolved_indy_entry_at() should be valid because the index is a known indy so it would not have a null _resolved_indy_entries. Calling the length function may be called when dumping, so does need to defend against null as you saw in the crash.
The resolved indy work went in JDK 21 baselevel 16 - don't know which update that would be though.

[matias9927]

I believe the constant pool cache refactor was introduced in JDK 21 which explains why older classlist files may cause some trouble. The fix looks good and I believe it should be sufficient as we don't tend to call resolved_indy_entry_at() if we know that _resolved_indy_entries is null. Thanks!

[jyukutyo]

Thank you for the reviews, Coleen and Matias!
Based on your feedback, I’ll proceed with integration.

[jyukutyo]

/integrate

[openjdk]

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

• 640b71d: 8365168: Use 64-bit aligned addresses for CK_ULONG access in PKCS11 native key code
• eca2032: 8365559: jarsigner shows files non-existent if signed with a weak algorithm
• 95577ca: 8361890: Aarch64: Removal of redundant dmb from C1 AtomicLong methods
• ... and 63 more: https://git.openjdk.org/jdk/compare/9c266ae83c047025d778da41e413701ac3b50b03...master

Your commit was automatically rebased without conflicts.

[openjdk]

@jyukutyo Pushed as commit 506625b.

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