JDK-8241603 : ZGC: java/lang/management/MemoryMXBean/MemoryTestZGC.sh crashes on macOS
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2020-03-25
  • Updated: 2022-02-24
  • Resolved: 2020-04-23
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 14 JDK 15
14.0.2Fixed 15 b21Fixed
Description
Every few days, the test java/lang/management/MemoryMXBean/MemoryTestZGC.sh crashes on macOS.
It is macOS 10.14.4, and it is a virtualized machine running with VMWare hypervisor.

stdout contains :
runOne -XX:+UnlockExperimentalVMOptions -XX:+UseZGC MemoryTest 1 1
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010c63e00e, pid=70959, tid=7427
#
# JRE version: OpenJDK Runtime Environment (15.0.0.1) (build 15.0.0.1-internal+0-adhoc.openjdk.jdk)
# Java VM: OpenJDK 64-Bit Server VM (15.0.0.1-internal+0-adhoc.openjdk.jdk, mixed mode, tiered, z gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x7b000e]  ZCPU::id_slow()+0x56
#
# Core dump will be written. Default location: ./core.70959
#
# An error report file with more information is saved as:
# /mymacworkdir/JTwork/java/lang/management/MemoryMXBean/MemoryTestZGC/hs_err_pid70959.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

backtrace from hserr :

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010c63e00e, pid=70959, tid=7427
#
# JRE version: OpenJDK Runtime Environment (15.0.0.1) (build 15.0.0.1-internal+0-adhoc.openjdk.jdk)
# Java VM: OpenJDK 64-Bit Server VM (15.0.0.1-internal+0-adhoc.openjdk.jdk, mixed mode, tiered, z gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x7b000e]  ZCPU::id_slow()+0x56
#
# Core dump will be written. Default location: ./core.70959
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=/mydir/jtreg_jdk_java_lang_management_work/tmp -Djava.io.tmpdir=/mydir/jtreg_jdk_java_lang_management_work/tmp -Djdk.test.lib.artifacts.devkit-macosx_x64=/mydir2/devkit/Xcode9.2-MacOSX10.13-devkit -ea -esa -XX:+UnlockExperimentalVMOptions -XX:+UseZGC MemoryTest 1 1

Host: MacPro6,1 x86_64 3337 MHz, 12 cores, 16G, Darwin 18.5.0
Time: Tue Mar 24 23:14:32 2020 CET elapsed time: 0.213331 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread (0x00007f9f81002600):  JavaThread "main" [_thread_in_vm, id=7427, stack(0x0000700007f60000,0x0000700008060000)]

Stack: [0x0000700007f60000,0x0000700008060000],  sp=0x000070000805ee30,  free space=1019k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x7b000e]  ZCPU::id_slow()+0x56
V  [libjvm.dylib+0x7bdfb3]  ZObjectAllocator::shared_small_page_addr() const+0x41
V  [libjvm.dylib+0x7be871]  ZObjectAllocator::remaining() const+0x9
V  [libjvm.dylib+0x7b3403]  ZHeap::unsafe_max_tlab_alloc() const+0xd
V  [libjvm.dylib+0x55de8d]  ThreadLocalAllocBuffer::compute_size(unsigned long)+0x33
V  [libjvm.dylib+0x55dd82]  MemAllocator::allocate_inside_tlab_slow(MemAllocator::Allocation&) const+0xca
V  [libjvm.dylib+0x55df72]  MemAllocator::mem_allocate(MemAllocator::Allocation&) const+0x24
V  [libjvm.dylib+0x55dfd3]  MemAllocator::allocate() const+0x47
V  [libjvm.dylib+0x329368]  InstanceKlass::allocate_instance(Thread*)+0x44
V  [libjvm.dylib+0x16a0c2]  Runtime1::new_instance(JavaThread*, Klass*)+0x84
v  ~RuntimeStub::fast_new_instance Runtime1 stub
J 59 c1 java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object; java.base@15.0.0.1-internal (300 bytes) @ 0x000000011a1d16e6 [0x000000011a1d06c0+0x0000000000001026]
J 66 c1 java.util.HashSet.add(Ljava/lang/Object;)Z java.base@15.0.0.1-internal (20 bytes) @ 0x000000011a1d3e34 [0x000000011a1d3be0+0x0000000000000254]
j  java.util.AbstractCollection.addAll(Ljava/util/Collection;)Z+29 java.base@15.0.0.1-internal
j  java.util.HashSet.<init>(Ljava/util/Collection;)V+35 java.base@15.0.0.1-internal
j  java.util.Set.copyOf(Ljava/util/Collection;)Ljava/util/Set;+17 java.base@15.0.0.1-internal
j  java.lang.ModuleLayer.modules()Ljava/util/Set;+19 java.base@15.0.0.1-internal
j  jdk.internal.module.ModuleBootstrap.addIllegalAccess(Ljava/lang/module/ModuleFinder;Ljava/util/Map;Ljava/util/Map;Ljava/lang/ModuleLayer;Z)V+277 java.base@15.0.0.1-internal
j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+1278 java.base@15.0.0.1-internal
j  java.lang.System.initPhase2(ZZ)I+0 java.base@15.0.0.1-internal
v  ~StubRoutines::call_stub
V  [libjvm.dylib+0x33fd90]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x256
V  [libjvm.dylib+0x33f6e7]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0xbb
V  [libjvm.dylib+0x72ffc1]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x66f
V  [libjvm.dylib+0x38f10b]  JNI_CreateJavaVM+0x60
C  [libjli.dylib+0x3e2d]  JavaMain+0x10b
C  [libjli.dylib+0x6b2c]  ThreadJavaMain+0x9
C  [libsystem_pthread.dylib+0x32eb]  _pthread_body+0x7e
C  [libsystem_pthread.dylib+0x6249]  _pthread_start+0x42
C  [libsystem_pthread.dylib+0x240d]  thread_start+0xd

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::fast_new_instance Runtime1 stub
J 59 c1 java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object; java.base@15.0.0.1-internal (300 bytes) @ 0x000000011a1d16e6 [0x000000011a1d06c0+0x0000000000001026]
J 66 c1 java.util.HashSet.add(Ljava/lang/Object;)Z java.base@15.0.0.1-internal (20 bytes) @ 0x000000011a1d3e34 [0x000000011a1d3be0+0x0000000000000254]
j  java.util.AbstractCollection.addAll(Ljava/util/Collection;)Z+29 java.base@15.0.0.1-internal
j  java.util.HashSet.<init>(Ljava/util/Collection;)V+35 java.base@15.0.0.1-internal
j  java.util.Set.copyOf(Ljava/util/Collection;)Ljava/util/Set;+17 java.base@15.0.0.1-internal
j  java.lang.ModuleLayer.modules()Ljava/util/Set;+19 java.base@15.0.0.1-internal
j  jdk.internal.module.ModuleBootstrap.addIllegalAccess(Ljava/lang/module/ModuleFinder;Ljava/util/Map;Ljava/util/Map;Ljava/lang/ModuleLayer;Z)V+277 java.base@15.0.0.1-internal
j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+1278 java.base@15.0.0.1-internal
j  java.lang.System.initPhase2(ZZ)I+0 java.base@15.0.0.1-internal
v  ~StubRoutines::call_stub
Comments
Fix request(14u): Requesting backport of this fix to 14u, as that release is affected as well. Patch applies cleanly but needs some minor adjustment to work in 14. Review thread can be found here: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-May/003063.html
01-05-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/f94239dfb99d User: pliden Date: 2020-04-23 13:38:19 +0000
23-04-2020

We solved our issue by reconfiguring the VMWare VM to have no hyperthreading and have the CPUs pinned to the VM. This solved the issues for us. Thanks for pointing us to VMWare.
30-03-2020

I am not aware that the issue occurs on bare metal, and yes we had the idea too that it might be related to VMWare. Thanks for pointing to the APIC ids issue. In (fast)debug I see timeouts, seems I do not reach the asserts there.
26-03-2020

I suspect that this is happening because you're running macOS on VMware, since there are known VMware bugs in the area of APIC ids (e.g. https://lore.kernel.org/patchwork/patch/733496/). Am I correct in assuming you don't see these problems when running macOS on bare metal? Can you try to reproduce this with a debug build? The assert in os::processor_id() should trigger, and it would be interesting to see what the invalid processor id is.
26-03-2020

These tests also timeout in the same context: compiler/gcbarriers/UnsafeIntrinsicsTest.java gc/z/TestAlwaysPreTouch.java gc/z/TestHighUsage.java gc/z/TestSmallHeap.java
26-03-2020

I should add that the other days, when the test doesn't terminate with a crash, we're getting timeouts.
25-03-2020