JDK-8277998 : runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#custom-cl-zgc failed "assert(ZAddress::is_marked(addr)) failed: Should be marked"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 18
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2021-11-30
  • Updated: 2021-12-16
  • Resolved: 2021-12-08
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 18 JDK 19
18 b28Fixed 19Fixed
Related Reports
Relates :  
JDK-8278602 - CDS dynamic dump may access unloaded classes
Relates :  
JDK-8274753 - ZGC: SEGV in MetaspaceShared::link_shared_classes
Relates :  
JDK-8278299 - CDS DynamicLoaderConstraintsTest.java/zgc failed "guarantee(offset <= MAX_SHARED_DELTA) failed: must be 32-bit offset"
Description
The following test failed in the JDK18 CI:

runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#custom-cl-zgc

Here's a snippet from the log file:

[0.205s][info][class,load              ] java.lang.invoke.LambdaForm$Holder
[0.209s][info][class,load              ] java.lang.Shutdown source: shared objects file
[0.209s][info][class,load              ] java.lang.Shutdown$Lock source: shared objects file
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/zBarrier.cpp:41
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/System/Volumes/Data/mesos/work_dir/slaves/a2dc162d-743b-4800-9e92-31f85abb45b1-S137615/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/83568f57-04bd-460f-88fd-51627cffb523/runs/fe04011a-4797-4735-bb60-897ff406a555/workspace/open/src/hotspot/share/gc/z/zBarrier.cpp:41), pid=16076, tid=43011
#  assert(ZAddress::is_marked(addr)) failed: Should be marked
#
# JRE version: Java(TM) SE Runtime Environment (18.0+26) (fastdebug build 18-ea+26-1760)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 18-ea+26-1760, mixed mode, sharing, tiered, compressed class ptrs, z gc, bsd-aarch64)
# Core dump will be written. Default location: core.16076
#
# An error report file with more information is saved as:
# /System/Volumes/Data/mesos/work_dir/slaves/a2dc162d-743b-4800-9e92-31f85abb45b1-S147880/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a38438c2-b97e-46f3-83d1-5e9ba0649a3e/runs/f7a128b3-9614-4f19-8479-6244d160faf4/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_tier2_runtime/scratch/2/hs_err_pid16076.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
];
 stderr: []
 exitValue = 134

java.lang.RuntimeException: Expected to get exit value of [0]

	at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:489)
	at jdk.test.lib.cds.CDSTestUtils$Result.assertNormalExit(CDSTestUtils.java:195)
	at DynamicLoaderConstraintsTest.doTest(DynamicLoaderConstraintsTest.java:166)
	at DynamicLoaderConstraintsTest.doTest(DynamicLoaderConstraintsTest.java:117)
	at DynamicArchiveTestBase.runTest(DynamicArchiveTestBase.java:74)
	at DynamicLoaderConstraintsTest.main(DynamicLoaderConstraintsTest.java:108)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:833)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [0]


Here's the crashing thread's stack:

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

Current thread (0x000000011f00d980):  VMThread "VM Thread" [stack: 0x000000016ee6c000,0x000000016f06f000] [id=43011]

Stack: [0x000000016ee6c000,0x000000016f06f000],  sp=0x000000016f06e520,  free space=2057k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x106b3ac]  VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x5d8
V  [libjvm.dylib+0x106bae4]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x40
V  [libjvm.dylib+0x59bbd8]  report_vm_error(char const*, int, char const*, char const*, ...)+0x80
V  [libjvm.dylib+0x10c40e8]  unsigned long ZBarrier::mark<false, true, false, true>(unsigned long)+0x98
V  [libjvm.dylib+0xfdb940]  oop ZBarrier::barrier<&(ZBarrier::is_good_or_null_fast_path(unsigned long)), &(ZBarrier::load_barrier_on_oop_slow_path(unsigned long))>(oop volatile*, oop)+0xa0
V  [libjvm.dylib+0x81832c]  AccessInternal::PostRuntimeDispatch<ZBarrierSet::AccessBarrier<548932ull, ZBarrierSet>, (AccessInternal::BarrierType)2, 548932ull>::oop_access_barrier(void*)+0x94
V  [libjvm.dylib+0x84aab4]  InstanceKlass::signers() const+0x34
V  [libjvm.dylib+0xf9340c]  SystemDictionaryShared::check_for_exclusion_impl(InstanceKlass*)+0x28c
V  [libjvm.dylib+0xf93134]  SystemDictionaryShared::check_for_exclusion(InstanceKlass*, DumpTimeClassInfo*)+0x188
V  [libjvm.dylib+0xf9543c]  SystemDictionaryShared::check_excluded_classes()+0x250
V  [libjvm.dylib+0x663620]  DynamicArchiveBuilder::doit()+0xd8
V  [libjvm.dylib+0x663418]  VM_PopulateDynamicDumpSharedSpace::doit()+0xac
V  [libjvm.dylib+0x1071b80]  VM_Operation::evaluate()+0x104
V  [libjvm.dylib+0x108d350]  VMThread::evaluate_operation(VM_Operation*)+0xe0
V  [libjvm.dylib+0x108de34]  VMThread::inner_execute(VM_Operation*)+0x33c
V  [libjvm.dylib+0x108d074]  VMThread::loop()+0xb4
V  [libjvm.dylib+0x108ce5c]  VMThread::run()+0xc0
V  [libjvm.dylib+0xfc5f28]  Thread::call_run()+0x21c
V  [libjvm.dylib+0xd98584]  thread_native_entry(Thread*)+0x160
C  [libsystem_pthread.dylib+0x74ec]  _pthread_start+0x94

VM_Operation (0x000000016d5d2788): PopulateDumpSharedSpace, mode: safepoint, requested by thread 0x000000011a012420
Comments
Changeset: e4852c6f Author: Calvin Cheung <ccheung@openjdk.org> Date: 2021-12-08 15:59:37 +0000 URL: https://git.openjdk.java.net/jdk/commit/e4852c6f0aa25e7d40c577d507aedc7916ee8d50
08-12-2021
This problem is similar to JDK-8274753
06-12-2021
[~stefank] It seems like LambdaFormInvokers::reload_class might be a possible culprit. After the class is parsed, we don't do anything to keep the class alive. The class is not added to the system dictionary (of the boot class loader). https://github.com/openjdk/jdk/blob/70bad89b012eb200ca1e76f384a6e5fb307cf26d/src/hotspot/share/cds/lambdaFormInvokers.cpp#L163 InstanceKlass* result = KlassFactory::create_from_stream(&st, class_name, cld, cl_info, CHECK); >>>> suggested fix add result.java_mirror() into a GrowableArrayCHeap<OopHandle, mtClassShared> to keep the class alive <<<<< { MutexLocker mu_r(THREAD, Compile_lock); // add_to_hierarchy asserts this. SystemDictionary::add_to_hierarchy(result); }
06-12-2021
I'm changing the subcomponent to Runtime. The assert says that the CDS code is reading a Klass that has not been kept alive. Is there any code that ensures that the Klasses in _dumptime_table and _dumptime_lambda_proxy_class_dictionary are kept alive when we are executing outside a safepoint?
06-12-2021