JDK-8211956 : AppCDS crashes for some uses with JRuby
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-10-09
  • Updated: 2019-01-15
  • Resolved: 2018-10-15
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
11.0.2Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Generating and using an AppCDS shared archive causes the JDK to SIGSEGV under certain scenarios.

I am working on a utility to assist users generating and using an AppCDS archive for JRuby. The command allows the user to pass a "typical" command line to use when generating the class list for AppCDS.

When passing the simplest command line, "-e 1" which does nothing but evaluate a literal "1", the generated AppCDS archive appears to work properly with any subsequent commands.

However when passing a more intensive command line, "-S gem list" which lists all installed "Ruby gems", the resulting archive fails with the SIGSEGV seen below.

Reproducing:

1. Unpack a JRuby dist from jruby.org and put its `bin` dir in PATH.
2. Clone the appcds utility I wrote from https://github.com/jruby/jruby-startup.git
3. From the jruby-startup dir, run `jruby -Ilib bin/generate-appcds "-S gem list"`
4. The script will create a "jruby.jsa" and provide environment variables to set to use it with JRuby.
5. Set those environment variables and run any command with JRuby (like "jruby -e 1") and the crash output below results.

Crash output at command line:

$ VERIFY_JRUBY=1 JAVA_OPTS='-XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=/Users/headius/projects/jruby/lib/jruby.jsa' jruby -e 1
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fff70857a6f, pid=89717, tid=7939
#
# JRE version:  (11.0+28) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11+28, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C  [libz.1.dylib+0xca6f]  gzclose_w+0xd7
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/headius/projects/jruby-startup/hs_err_pid89717.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
/Users/headius/projects/jruby/bin/jruby: line 425: 89717 Abort trap: 6           "$JAVACMD" $PROFILE_ARGS $JAVA_OPTS "$JFFI_OPTS" "${java_args[@]}" --module-path "$JRUBY_CP$CP_DELIMITER$CP$CP_DELIMITER$CLASSPATH" "-Djruby.home=$JRUBY_HOME" "-Djruby.lib=$JRUBY_HOME/lib" -Djruby.script=jruby "-Djruby.shell=$JRUBY_SHELL" $java_class $mode "$@"

real	0m0.165s
user	0m0.071s
sys	0m0.083s

I will attach the full error dump file.
Comments
[~robm]Thanks for the approval! The back port is pushed.
16-10-2018

Fix is out for review: http://cr.openjdk.java.net/~jiangli/8211956/webrev.00/.
13-10-2018

I reproduced the failure as well on mac os this morning, and was finally able to reproduce it on linux x64. I needed to set the gc heap size in the environment valuable on linux machine for jruby. I also checked against JDK 12, it failed with an assert with a debug build. [~headius]A safer temporary workaround is to explicitly set the GC heap size to 4G (or larger) with '-Xmx4G -Xms4G' for both the dump time and runtime. That forces 2m GC region being used and the archived ST or OA heap data can fit into one archive space. Another safer workaround to use '-XX:G1HeapRegionSize=2m' in the dump time command and runtime command. That sets the GC region size directly regardless of the heap size. I've verified both workarounds on my mac laptop and the crash was gone with them. The fix is trivial. I'm working on fixing it soon. Thanks.
12-10-2018

I'm glad I wasn't going crazy! Informational: the default command line for generate-appcds looks like it sees 6772 classes. With "-S gem list" it sees 7482 classes (this will vary with how many gems are installed, I suspect). So the tipping point is somewhere in there. I suspected I was crossing some line like this, but I was not sure if there were any tuning arguments I could use to tweak it. What's the worst that can happen with -VerifySharedSpaces? I *am* getting some nice startup improvements from this, and would like to have others try it out sooner than you can probably get a fix into a release...
12-10-2018

I can also force the crash to happen on Linux. I needed to run with $ JAVA_TOOL_OPTIONS="-Xlog:gc -Xmx256m" jruby -Ilib bin/generate-appcds "-S gem list" $ VERIFY_JRUBY=1 \ JAVA_OPTS="-Xmx256m -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=/home/iklam/jruby/jruby-9.2.1.0-SNAPSHOT/lib/jruby.jsa" \ jruby -e 1 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f9d466ec908, pid=32688, tid=32689 # # JRE version: (11.0+28) (build ) # Java VM: OpenJDK 64-Bit Server VM (11+28, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C [libz.so.1+0x2908] crc32+0x38
12-10-2018

Changed priority to P2. The crash affects larger archives that have roughly 5000+ classes, which would have enough objects to spill into the "oa1" region. This this bug has wide impact. Unaffected archive (no "oa1"): mc space: 13672 [ 0.0% of total] out of 16384 bytes [ 83.4% used] at 0x0000000800000000 rw space: 15761144 [ 25.4% of total] out of 15761408 bytes [100.0% used] at 0x0000000800004000 ro space: 22399096 [ 36.1% of total] out of 22401024 bytes [100.0% used] at 0x0000000800f0c000 md space: 2560 [ 0.0% of total] out of 4096 bytes [ 62.5% used] at 0x0000000802469000 od space: 21462424 [ 34.6% of total] out of 21463040 bytes [100.0% used] at 0x000000080246a000 st0 space: 405504 [ 0.7% of total] out of 405504 bytes [100.0% used] at 0x00000007bfe00000 st1 space: 1048576 [ 1.7% of total] out of 1048576 bytes [100.0% used] at 0x00000007bff00000 oa0 space: 987136 [ 1.6% of total] out of 987136 bytes [100.0% used] at 0x00000007bfd00000 Affected archive (with "oa1"): mc space: 13888 [ 0.0% of total] out of 16384 bytes [ 84.8% used] at 0x0000000800000000 rw space: 17227968 [ 25.7% of total] out of 17231872 bytes [100.0% used] at 0x0000000800004000 ro space: 23959416 [ 35.8% of total] out of 23961600 bytes [100.0% used] at 0x0000000801073000 md space: 2560 [ 0.0% of total] out of 4096 bytes [ 62.5% used] at 0x000000080274d000 od space: 23112560 [ 34.5% of total] out of 23113728 bytes [100.0% used] at 0x000000080274e000 st0 space: 528384 [ 0.8% of total] out of 528384 bytes [100.0% used] at 0x00000007bfe00000 st1 space: 1048576 [ 1.6% of total] out of 1048576 bytes [100.0% used] at 0x00000007bff00000 oa0 space: 40960 [ 0.1% of total] out of 40960 bytes [100.0% used] at 0x00000007bfc00000 oa1 space: 1048576 [ 1.6% of total] out of 1048576 bytes [100.0% used] at 0x00000007bfd00000
12-10-2018

The bug is in here http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/memory/filemap.cpp#l996 bool FileMapInfo::verify_mapped_heap_regions(int first, int num) { for (int i = first; i <= first + num; i++) { //<<<<<<<< HERE: should be "<" instead of "<=" if (!verify_region_checksum(i)) { return false; } } return true; } gdb shows: Breakpoint 1, FileMapInfo::verify_region_checksum (this=0x7fd535608810, i=9) at filemap.cpp:1032 (gdb) c Continuing. Breakpoint 2, FileMapInfo::verify_region_checksum (this=0x7fd535608810, i=<value temporarily unavailable, due to optimizations>) at filemap.cpp:1048 (gdb) info locals sz = 6206086066621015379 buf = 0x207469422d343620 <Address 0x207469422d343620 out of bounds> i=9 is not a valid region. The max allowed region number is 8. [~headius] - the work around is to specify -XX:-VerifySharedSpaces until this bug is fixed, hopefully in the next JDK 11 update release.
12-10-2018

With official JDK 11, and https://projectodd.ci.cloudbees.com/view/JRuby/job/jruby-development-dist/lastSuccessfulBuild/artifact/release/jruby-bin-9.2.1.0-SNAPSHOT.tar.gz (23767865 bytes, cksum = 2094758907), and the command-line jruby -Ilib bin/generate-appcds "-S gem list" I can reproduce the same crash on OSX (Darwin Iois-MacBook-Pro.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 21 20:07:39 PDT 2018; root:xnu-3789.73.14~1/RELEASE_X86_64 x86_64), but cannot reproduce on Linux. As [~headius] mentioned, a simple archive generated with the following command-line will not crash jruby -Ilib bin/generate-appcds
12-10-2018

Ah-ha, I may have led you somewhat astray. I assumed that my master branch, JRuby 9.2.1, would behave the same as the release version 9.2. I just now tested 9.2 and indeed I cannot reproduce. Instead I get the following error, when I try to generate-appcds '-S gem list': Loading classes to share: done. Rewriting and linking classes ... Rewriting and linking classes: done Number of classes 7312 instance classes = 7233 obj array classes = 71 type array classes = 8 Updating ConstMethods ... done. Removing unshareable information ... done. Failed allocating metaspace object type TypeArrayU8 of size 2712. CDS dump aborted. Please increase MaxMetaspaceSize (currently 18446744073709547520 bytes). So I pulled down a snapshot build from here instead: https://projectodd.ci.cloudbees.com/view/JRuby/job/jruby-development-dist/lastSuccessfulBuild/artifact/release/ With this version unpacked and in PATH, I am able to reproduce again. I can also confirm that disabling VerifySharedSpaces prevents the crash: [] ~/projects/jruby $ VERIFY_JRUBY=1 JAVA_OPTS='-XX:SharedArchiveFile=/Users/headius/projects/jruby/lib/jruby.jsa' jruby -e 1 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fff774bda6f, pid=19941, tid=8963 # # JRE version: (11.0+28) (build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (11+28, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, bsd-amd64) # Problematic frame: # C [libz.1.dylib+0xca6f] gzclose_w+0xd7 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/headius/projects/jruby/hs_err_pid19941.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # /Users/headius/projects/jruby/bin/jruby: line 426: 19941 Abort trap: 6 "$JAVACMD" $PROFILE_ARGS $JAVA_OPTS "$JFFI_OPTS" "${java_args[@]}" -classpath "$JRUBY_CP$CP_DELIMITER$CP$CP_DELIMITER$CLASSPATH" "-Djruby.home=$JRUBY_HOME" "-Djruby.lib=$JRUBY_HOME/lib" -Djruby.script=jruby "-Djruby.shell=$JRUBY_SHELL" $java_class $mode "$@" [] ~/projects/jruby $ VERIFY_JRUBY=1 JAVA_OPTS='-XX:-VerifySharedSpaces -XX:SharedArchiveFile=/Users/headius/projects/jruby/lib/jruby.jsa' jruby -e 1 WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.jruby.util.SecurityHelper (file:/Users/headius/projects/jruby/lib/jruby.jar) to field java.lang.reflect.Field.modifiers WARNING: Please consider reporting this to the maintainers of org.jruby.util.SecurityHelper WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release
12-10-2018

[~headius] Try adding -XX:-VerifySharedSpaces and see if it stops crashing. If so, it might be some problem with crc32_z. Then, try the following to see if you can get the second command to crash. java -Xshare:dump java -Xshare:on -XX:-VerifySharedSpaces -version FYI, VerifySharedSpaces is enabled by default only when -XX:SharedArchiveFile is specified (as in the case of the initially reported crash).
12-10-2018

[~jiangli] It is JDK-8205012. The version info is dumped before the flags get their final values.
12-10-2018

To eliminate the effect of GC region size difference, I modified lib/jruby/startup/appcds.rb and added -Xmx128m -Xmx128 (GC region is 1M with 128M java heap) to the dumping step and also added to the runtime. Both the close and open archive heap regions have two sub-regions. jruby-startup-master% jruby -J-XX:SharedArchiveFile=/export/users/jiangli/jruby/jruby-9.2.0.0/lib/jruby.jsa -J-Xms128m -J-Xms128m -J-showversion -e 1 java version "11" 2018-09-25 Java(TM) SE Runtime Environment 18.9 (build 11+28) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode, sharing) Still could not reproduce the failure. [~headius]If you spot anything that I'm missing in my steps, please let me know. Thanks.
11-10-2018

[~dholmes]Thanks for the info. Do you have the version string bug number?
11-10-2018

Still can't reproduce yet. Here are the steps that I used on linux-x64: 1. download jruby-9.2.0.0 dis 2. setenv PATH to include jruby-9.2.0.0/bin 4. download JDK 11 b28 5. set JAVA_HOME to idk 11 b28 6. setenv CLASSPATH 7. jruby-startup-master% jruby -Ilib bin/generate-appcds "-S gem list" I needed to increase MaxMetaspaceSize jruby-startup-master% jruby -Ilib bin/generate-appcds "-S gem list" *** Outputting list of classes at /export/users/jiangli/jruby/jruby-9.2.0.0/lib/jruby.jsa skip writing class com/sun/proxy/$Proxy0 from source __JVM_DefineClass__ to classlist file skip writing class com/sun/proxy/jdk/proxy1/$Proxy7 from source __JVM_DefineClass__ to classlist file skip writing class com/sun/proxy/$Proxy8 from source __JVM_DefineClass__ to classlist file skip writing class com/sun/proxy/$Proxy16 from source __JVM_DefineClass__ to classlist file skip writing class com/sun/proxy/$Proxy23 from source __JVM_DefineClass__ to classlist file *** LOCAL GEMS *** cmath (default: 1.0.0) csv (default: 1.0.0) fileutils (default: 1.1.0) ipaddr (default: 1.2.0) jar-dependencies (default: 0.3.12) jruby-openssl (default: 0.10.0 java) jruby-readline (default: 1.2.2 java) json (default: 2.1.0 java) psych (default: 3.0.2 java) rake-ant (default: 1.0.4) rdoc (default: 6.0.1) scanf (default: 1.0.0) webrick (default: 1.4.2) *** Generating shared AppCDS archive at /export/users/jiangli/jruby/jruby-9.2.0.0/lib/jruby.jsa [0.005s][info][class,path] bootstrap loader class path=/export/users/jiangli/binary/jdk-11/lib/modules [0.005s][info][class,path] type=BOOT [0.005s][info][class,path] add misc shared path /export/users/jiangli/binary/jdk-11/lib/modules [0.005s][info][class,path] opened: /export/users/jiangli/binary/jdk-11/lib/modules narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3 Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000 Allocated shared space: 3221225472 bytes at 0x0000000800000000 [0.018s][info][class,path] app loader class path=/export/users/jiangli/jruby/jruby-9.2.0.0/lib/jruby.jar:: [0.018s][info][class,path] type=APP [0.018s][info][class,path] add misc shared path /export/users/jiangli/jruby/jruby-9.2.0.0/lib/jruby.jar:: [0.020s][info][class,path] opened: /export/users/jiangli/jruby/jruby-9.2.0.0/lib/jruby.jar [0.089s][info][class,path] add main shared path (jrt) /export/users/jiangli/binary/jdk-11/lib/modules [0.089s][info][class,path] add app shared path /export/users/jiangli/jruby/jruby-9.2.0.0/lib/jruby.jar Loading classes to share ... Preload Warning: Cannot find com/sun/proxy/$Proxy1 Preload Warning: Cannot find com/sun/proxy/$Proxy2 Preload Warning: Cannot find com/sun/proxy/$Proxy3 Preload Warning: Cannot find com/sun/proxy/$Proxy4 Preload Warning: Cannot find com/sun/proxy/$Proxy5 Preload Warning: Cannot find com/sun/proxy/$Proxy6 Preload Warning: Cannot find com/sun/proxy/$Proxy9 Preload Warning: Cannot find com/sun/proxy/$Proxy10 Preload Warning: Cannot find com/sun/proxy/$Proxy11 Preload Warning: Cannot find com/sun/proxy/$Proxy12 Preload Warning: Cannot find com/sun/proxy/$Proxy13 Preload Warning: Cannot find com/sun/proxy/$Proxy14 Preload Warning: Cannot find com/sun/proxy/$Proxy15 Preload Warning: Cannot find com/sun/proxy/$Proxy17 Preload Warning: Cannot find com/sun/proxy/$Proxy18 Preload Warning: Cannot find com/sun/proxy/$Proxy19 Preload Warning: Cannot find com/sun/proxy/$Proxy20 Preload Warning: Cannot find com/sun/proxy/$Proxy21 Preload Warning: Cannot find com/sun/proxy/$Proxy22 Preload Warning: Cannot find com/sun/proxy/$Proxy24 Preload Warning: Cannot find com/sun/proxy/$Proxy25 Preload Warning: Cannot find com/sun/proxy/$Proxy26 Preload Warning: Cannot find com/sun/proxy/$Proxy27 Preload Warning: Cannot find com/sun/proxy/$Proxy28 Loading classes to share: done. Rewriting and linking classes ... Rewriting and linking classes: done Number of classes 7325 instance classes = 7246 obj array classes = 71 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: 13720 [ 0.0% of total] out of 16384 bytes [ 83.7% used] at 0x0000000800000000 rw space: 17052016 [ 25.8% of total] out of 17055744 bytes [100.0% used] at 0x0000000800004000 ro space: 23589216 [ 35.7% of total] out of 23592960 bytes [100.0% used] at 0x0000000801048000 md space: 2560 [ 0.0% of total] out of 4096 bytes [ 62.5% used] at 0x00000008026c8000 od space: 22786872 [ 34.5% of total] out of 22790144 bytes [100.0% used] at 0x00000008026c9000 st0 space: 1564672 [ 2.4% of total] out of 1564672 bytes [100.0% used] at 0x00000007ffc00000 oa0 space: 1081344 [ 1.6% of total] out of 1081344 bytes [100.0% used] at 0x00000007ff800000 total : 66090400 [100.0% of total] out of 66105344 bytes [100.0% used] java version "11" 2018-09-25 Java(TM) SE Runtime Environment 18.9 (build 11+28) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) *** Success! Set the following environment variables to use the shared archive: VERIFY_JRUBY=1 JAVA_OPTS=-XX:SharedArchiveFile=/export/users/jiangli/jruby/jruby-9.2.0.0/lib/jruby.jsa 8. setenv VERIFY_JRUBY 1 9. setenv JAVA_OPTS -XX:SharedArchiveFile=/export/users/jiangli/jruby/jruby-9.2.0.0/lib/jruby.jsa 10. jruby-startup-master% jruby -e 1 There are some differences between Charles' dumping output and mine. In Charles' dumping output, I two closed archive heap region (st): mc space: 13672 [ 0.0% of total] out of 16384 bytes [ 83.4% used] at 0x0000000800000000 rw space: 15761144 [ 25.4% of total] out of 15761408 bytes [100.0% used] at 0x0000000800004000 ro space: 22399096 [ 36.1% of total] out of 22401024 bytes [100.0% used] at 0x0000000800f0c000 md space: 2560 [ 0.0% of total] out of 4096 bytes [ 62.5% used] at 0x0000000802469000 od space: 21462424 [ 34.6% of total] out of 21463040 bytes [100.0% used] at 0x000000080246a000 st0 space: 405504 [ 0.7% of total] out of 405504 bytes [100.0% used] at 0x00000007bfe00000 st1 space: 1048576 [ 1.7% of total] out of 1048576 bytes [100.0% used] at 0x00000007bff00000 oa0 space: 987136 [ 1.6% of total] out of 987136 bytes [100.0% used] at 0x00000007bfd00000 total : 62080112 [100.0% of total] out of 62087168 bytes [100.0% used]
11-10-2018

There is (was?) a bug with how the version string is put together that causes AOT to be reported when in fact it is not used.
11-10-2018

We are not using AOT in this example at all...just AppCDS.
11-10-2018

[~headius]Thanks for the additional information. Could you please provide the command for how AOT library is created. I'll try that also. Thanks. A side note, AOT is currently an experimental feature. Using CDS/AppCDS with AOT is not a fully tested.
11-10-2018

I am not running with any libraries AOT...but perhaps java.base or others are?
11-10-2018

From the reported crash output, I see AOT is used. # # JRE version: (11.0+28) (build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (11+28, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, bsd-amd64) There was a known bug with AOT and AppCDS, which caused crash because wrong compressed oop encoding mode was used at runtime when both AOT and AppCDS was enabled. The bug was fixed. The reported issue might be related to that bug. I'll dig it up.
11-10-2018

I also fixed the rogue "1" in the "gem list" part of my description. That was a typo.
11-10-2018

I just reproduced again locally. I am on MacOS, and Tom Enebo was able to reproduce with a current JDK11 on Linux. https://gist.github.com/headius/7c34ff270ff2633f8f3a6f27b78c4746 This gist shows how to pull down the latest jruby-startup gem and run the commands to reproduce. Does it work ok for you?
11-10-2018

I haven't been able to reproduce the crash yet. I tried both JDK 12 and JDK 11. With JDK 12, "jruby -e 1" works after the `jruby -Ilib bin/generate-appcds "-S gem list"` step. Notes: Seems there is a typo (the ending '1' in the jruby command) in step 3. With `jruby -Ilib bin/generate-appcds "-S gem list"1`, there is following error. ERROR: While executing gem ... (Gem::CommandLineError) Unknown command list1 With JDK 11, I'm getting 'Error: non-empty directory '.'' with `jruby -Ilib bin/generate-appcds "-S gem list"` when it's generating the archive. Resolving the non-empty directory error, JDK 11 also works without crash.
11-10-2018

[~headius]Thanks for reporting the issue. From the hs_err log, the crash happens during mapping and validating the archiving heap region. I'm downloading the jruby bundle and trying to reproduce.
11-10-2018

Current thread's stack trace from the err file, for convenience: Current thread (0x00007fdbc6802000): JavaThread "Unknown thread" [_thread_in_vm, id=7939, stack(0x00000001000df000,0x00000001002df000)] Stack: [0x00000001000df000,0x00000001002df000], sp=0x00000001002dea60, free space=2046k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libz.1.dylib+0xca6f] gzclose_w+0xd7 C [libz.1.dylib+0x1964] crc32_z+0x30d V [libjvm.dylib+0x2f169d] FileMapInfo::verify_region_checksum(int)+0x91 V [libjvm.dylib+0x2f1aae] FileMapInfo::map_heap_data(MemRegion**, int, int, int*, bool)+0x1ce V [libjvm.dylib+0x2f1801] FileMapInfo::map_heap_regions()+0x139 V [libjvm.dylib+0x5b6cde] MetaspaceShared::initialize_runtime_shared_and_meta_spaces()+0x8c V [libjvm.dylib+0x5b4720] Metaspace::global_initialize()+0x40 V [libjvm.dylib+0x7193d9] universe_init()+0x4c V [libjvm.dylib+0x38d87b] init_globals()+0x4b V [libjvm.dylib+0x7045c5] Threads::create_vm(JavaVMInitArgs*, bool*)+0x26d V [libjvm.dylib+0x3fae30] JNI_CreateJavaVM+0x60 C [java+0x3e50] JavaMain+0x10b C [libsystem_pthread.dylib+0x3661] _pthread_body+0x154 C [libsystem_pthread.dylib+0x350d] _pthread_body+0x0 C [libsystem_pthread.dylib+0x2bf9] thread_start+0xd
09-10-2018