JDK-8226406 : JVM fails to detect mismatched or corrupt CDS archive
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-06-19
  • Updated: 2020-02-05
  • Resolved: 2019-07-12
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 11 JDK 13 JDK 14
11.0.7-oracleFixed 13 b30Fixed 14Fixed
Related Reports
Relates :  
JDK-8227370 - Remove SharedPathsMiscInfo
Relates :  
JDK-8228407 - JVM crashes with shared archive file mismatch
Description
The failure doesn't always happen, but it's more likely to happen when your BOOT_JDK is significantly different than the JDK sources in both age and 32/64 bit-ness.
=========
$ ./jdk-14-32bit/bin/java -version
java version "14-internal" 2020-03-17
Java(TM) SE Runtime Environment (build 14-internal+0-2019-06-19-0325035.iklam.null)
Java HotSpot(TM) Server VM (build 14-internal+0-2019-06-19-0325035.iklam.null, mixed mode, sharing)

$ ./jdk-12-64bit/bin/java -version
java version "12" 2019-03-19
Java(TM) SE Runtime Environment (build 12+33)
Java HotSpot(TM) 64-Bit Server VM (build 12+33, mixed mode, sharing)

$ ./jdk-12-64bit/bin/java -Xshare:dump -XX:SharedArchiveFile=jdk-12-64bit.jsa
Allocated shared space: 3221225472 bytes at 0x0000000800000000
Loading classes to share ...
Loading classes to share: done.
Reading extra data: done.
Rewriting and linking classes ...
Rewriting and linking classes: done
Number of classes 1244
    instance classes   =  1176
    obj array classes  =    60
    type array classes =     8
Updating ConstMethods ... done. 
Removing unshareable information ... done. 
Scanning all metaspace objects ... 
Allocating RW objects ... 
Allocating RO objects ... 
Relocating embedded pointers ... 
Relocating external roots ... 
Dumping symbol table ...
Dumping objects to closed archive heap region ...
Dumping objects to open archive heap region ...
Relocating SystemDictionary::_well_known_klasses[] ... 
Removing java_mirror ... done. 
mc  space:      8560 [  0.0% of total] out of     12288 bytes [ 69.7% used] at 0x0000000800000000
rw  space:   4021160 [ 21.4% of total] out of   4022272 bytes [100.0% used] at 0x0000000800003000
ro  space:   7380296 [ 39.3% of total] out of   7380992 bytes [100.0% used] at 0x00000008003d9000
md  space:      2368 [  0.0% of total] out of      4096 bytes [ 57.8% used] at 0x0000000800ae3000
od  space:   6576528 [ 35.1% of total] out of   6578176 bytes [100.0% used] at 0x0000000800ae4000
ca0 space:    466944 [  2.5% of total] out of    466944 bytes [100.0% used] at 0x00000007bfc00000
oa0 space:    290816 [  1.6% of total] out of    290816 bytes [100.0% used] at 0x00000007bf800000
total    :  18746672 [100.0% of total] out of  18755584 bytes [100.0% used]

$ ./jdk-14-32bit/bin/java -Xshare:auto -XX:SharedArchiveFile=jdk-12-64bit.jsa -XX:+VerifySharedSpaces -version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xf76a8ed9, pid=16082, tid=16083
#
# JRE version:  (14.0) (build )
# Java VM: Java HotSpot(TM) Server VM (14-internal+0-2019-06-19-0325035.iklam.null, mixed mode, tiered, g1 gc, linux-x86)
# Problematic frame:
# C  [libz.so.1+0x1ed9]  crc32+0x159
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /jdk/dre/build/core.16082)
#
# An error report file with more information is saved as:
# /jdk/dre/build/hs_err_pid16082.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Aborted (core dumped)


========
For another crash scenario, see JDK-8226404 "bootcycle build uses wrong CDS archive"
Comments
Fix request (11u) I would like to downport this for parity with 11.0.7-oracle. I had to do several adaptions to the change to get it into 11: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002430.html
28-01-2020
URL: https://hg.openjdk.java.net/jdk/jdk13/rev/7b7df2be6219 User: ccheung Date: 2019-07-12 15:40:53 +0000
12-07-2019
I've created JDK-8227370 for the removal of SharedPathsMiscInfo. Please see details in the RFE description. I think this bug fix should be handled as part of the removal of SharedPathsMiscInfo.
07-07-2019
ILW = HLM = P3
27-06-2019
I could reproduce the crash by changing the value of _paths_misc_info_size in the shared archive header to a large number. Attached is a modified version of the existing test runtime/appcds/SharedArchiveConsistency.java. The VM crashes in the following scenario: + // modify _paths_misc_info_size, test should fail # Internal Error (open/src/hotspot/share/memory/guardedMemory.hpp:293), pid=54254, tid=54257 # assert(total_size > user_size) failed: Unexpected wrap-around Call stack: Stack: [0x00007f35bec63000,0x00007f35bed64000], sp=0x00007f35bed62980, free space=1022k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x13dee94] os::malloc(unsigned long, MemoryType, NativeCallStack const&)+0x314 V [libjvm.so+0x5cac91] AllocateHeap(unsigned long, MemoryType, AllocFailStrategy::AllocFailEnum)+0x91 V [libjvm.so+0xbbe96b] FileMapInfo::init_from_file(int, bool)+0x8b V [libjvm.so+0xbbfc41] FileMapInfo::initialize(bool)+0x81 V [libjvm.so+0x12e53a2] MetaspaceShared::initialize_runtime_shared_and_meta_spaces()+0x52 V [libjvm.so+0x12ddf6d] Metaspace::global_initialize()+0xed V [libjvm.so+0x17162e4] universe_init()+0xd4 V [libjvm.so+0xdab443] init_globals()+0x63 V [libjvm.so+0x16d3feb] Threads::create_vm(JavaVMInitArgs*, bool*)+0x28b V [libjvm.so+0xef7859] JNI_CreateJavaVM+0x99 C [libjli.so+0x40ef] JavaMain+0x7f C [libjli.so+0x8159] ThreadJavaMain+0x9
27-06-2019
The current thinking is moving the following jvm identifier field form FileMapHead to CDSFileMapHeaderBase: char _jvm_ident[JVM_IDENT_MAX]; // identifier for jvm Also add another "magic", say _end_magic at the end of the CDSFileMapHeaderBase. The _magic, _jvm_ident, and _end_magic should be checked first prior to using any field from the CDS archive header.
19-06-2019
The SharedPathsMiscInfo has been causing other types of issues in the past (please see JDK-8211723). I was hoping to see it being addressed as part of the work for dynamic archive. A longer term solution to help move to the right direction is eliminating the use of SharedPathsMiscInfo completely. Following is a proposed solution copied from JDK-8211723. ------------------------------- We can remove the separate runtime path check using the os::file_name_strncmp() call in classfile/sharedPathsMiscInfo.cpp. The reason for the check is to ensure the ordering of the runtime paths is the same as the dump time paths and also to make sure there is no new path component added in front any of the dump time existing path components. Then we can also remove the problematic os::file_name_strncmp(). We should instead do the ordering check in FileMapInfo::validate_shared_path_table(). FileMapInfo::validate_shared_path_table() iterates through the recorded shared path table and validates each dump time path. To include the ordering check here, we can get the runtime class_path using Arguments::get_appclasspath() and compare each runtime class_path component in canonical form with the recorded shared table element. Benefits of this approach: 1.More efficient than doing two separate checks 2.Help clean up the code 3.Lift some of the current restrictions imposed by the os::file_name_strncmp() check. It would allow us to support more cases with valid runtime path usage but rejected by the os::file_name_strncmp() check. For example the mixed usages of absolute path and relative path at runtime and dump time. Usage of symbolic link to file would also be allowed. ------------------------------------- Addressing the SharedPathsMiscInfo problem properly will help avoid further bandaging the issues when they surface and reduce maintenance cost.
19-06-2019
There is a pre-mature accessing of the _paths_misc_info_size from the archive file and allocation of memory using the size, before the archive header validation (validate_header()). The archive validation should be done first.
19-06-2019