JDK-8274944 : AppCDS dump causes SEGV in VM thread while adjusting lambda proxy class info
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2021-10-06
  • Updated: 2022-07-12
  • Resolved: 2021-10-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 18
17.0.3-oracleFixed 18 b21Fixed
Related Reports
Blocks :  
JDK-8264735 - Make dynamic dump repeatable
Duplicate :  
JDK-8276997 - CDS archive creation fails with SIGSEGV
Description
ADDITIONAL SYSTEM INFORMATION :
Linux 5.14.9-100.fc33.x86_64 x86_64 CentOS 8

A DESCRIPTION OF THE PROBLEM :
We have a moderately complicated Java test integration application that loads a number of isolated environments in custom ClassLoaders. In order to improve startup time, we want to adopt CDS, but initial attempts to follow the CDS guide and run -XX:ArchiveClassesAtExit lead to a JVM crash. Reproduced in 16.0.1, 17 GA, and a slowdebug build of 17u at 393547b2. The release builds crash with a SEGV, so I tried the slowdebug build to see if it gave more information, and it trips an assertion instead.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/service/jdk17u/src/hotspot/share/cds/archiveBuilder.hpp:296), pid=142855, tid=142874
#  assert(is_in_buffer_space(obj)) failed: must be
#
# JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.service.jdk17u)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.service.jdk17u, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x510f62]  unsigned char* ArchiveBuilder::to_requested<unsigned char*>(unsigned char*) const+0x34
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /usr/local/lib/service/core.142855)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

(see attached hs err log for details)
Comments
Fix request [17u] I backport this for parity with 17.0.3-oracle. It applies clean, but I had to adapt a test. I think there is no technical reason for the "blocked" relation to JDK-8264735. I could not find any comments why this was added. If I run the test appcds/dynamicArchive/LambdaContainsOldInf.java without the fix I get a crash. If I run it with the fix the test passes. I had to remove the check for "Skipping OldProvider: Old class has been linked' missing from stdout/stderr" The change depends on "JDK-8271506: Add ResourceHashtable support for deleting selected entries" which does not fit well into 17 because "8269004: Implement ResizableResourceHashtable" is missing. I reworked the code to adapt it to the ResourceHashtable of 17 and made a seperate PR. The test appcds/dynamicArchive/LambdaContainsOldInf.java fails as-is. It does not use OldProvider at all because of "Pre JDK 6 class not supported by CDS: 49.0 OldProvider". Therefore later "Skipping OldProvider: Old class has been linked' missing from stdout/stderr" is not found in the output. Removing that check makes the test pass.
31-01-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/133 Date: 2022-01-31 09:16:17 +0000
31-01-2022
Looks like 17u backport depends on JDK-8264735.
06-01-2022
Changeset: e5cd2692 Author: Calvin Cheung <ccheung@openjdk.org> Date: 2021-10-26 16:26:57 +0000 URL: https://git.openjdk.java.net/jdk/commit/e5cd2692da6327c6fde954f86595a08fe5edf43f
26-10-2021
I think the fix should be back ported to 17.
26-10-2021
The java/inject/Provider interface has a major version of 49. Below is an excerpt of output from javap: public interface javax.inject.Provider<T extends java.lang.Object> minor version: 0 major version: 49 The CdsTest class has a lambda proxy class (e.g. CdsTest$$Lambda$1/0x0000000800c00bf8) which contains the above interface due to the following code: public static Provider<Object> getProvider() { return () -> { We currently don't support archiving classes with major version < 50 which have been linked during dump time. Since the lambda proxy class of CdsTest contains an interface which cannot be archived, we should also skip archiving the lambda proxy class.
19-10-2021
Additional Information from submitter: =========================== I managed to significantly narrow down the scope of the problem. It appears to be using a lambda expression to implement javax.inject.Provider (from Jakarta inject-api). Using an abstract class does not cause CDS errors. Copying the source for Provider and using the local copy does not cause CDS errors. Only when linking the Jakarta artifact from Maven Central does CDS crash. To reproduce, Fetch well-known inject api jar: curl -L -o inject-api.jar 'https://search.maven.org/remotecontent?filepath=jakarta/inject/jakarta.inject-api/1.0.3/jakarta.inject-api-1.0.3.jar' Compile the source: import javax.inject.Provider; public class CdsTest { public static void main(final String... args) { getProvider(); } public static Provider<Object> getProvider() { return () -> { return null; }; } } Create a JAR of it: jar --create --file CdsTest.jar CdsTest.class Attempt to archive CDS at exit: % java -XX:ArchiveClassesAtExit=test.jsa -cp CdsTest.jar:inject-api.jar CdsTest [0.094s][warning][cds] Pre JDK 6 class not supported by CDS: 49.0 javax/inject/Provider [0.094s][warning][cds] Skipping CdsTest$$Lambda$1+0x0000000800c00c08: Old class has been linked # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fe343b989b0, pid=274380, tid=274387 # # JRE version: OpenJDK Runtime Environment 21.9 (17.0+35) (build 17+35) # Java VM: OpenJDK 64-Bit Server VM 21.9 (17+35, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xe849b0] SystemDictionaryShared::adjust_lambda_proxy_class_dictionary()+0xa0 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /home/######/#######/############/######/core.274380) # # An error report file with more information is saved as: # /home/######/#######/############/######/hs_err_pid274380.log
18-10-2021
ILW = HLM = P3
12-10-2021
The crash is in ArchiveBuilder (cds) # Problematic frame: # V [libjvm.so+0x510f62] unsigned char* ArchiveBuilder::to_requested<unsigned char*>(unsigned char*) const+0x34 # Internal Error (/home/service/jdk17u/src/hotspot/share/cds/archiveBuilder.hpp:296), pid=142855, tid=142874 # assert(is_in_buffer_space(obj)) failed: It is observed on OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.service.jdk17u). Submitter is not able to share a reproducer due to large application size.
08-10-2021