JDK-8210422 : runtime/modules/ModuleStress/ExportModuleStressTest.java - assertion failed: address not aligned: 0x00000008baadbabe
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-09-05
  • Updated: 2021-02-23
  • Resolved: 2018-09-11
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 12
11-poolUnresolved 12 b11Fixed
Related Reports
Duplicate :  
JDK-8210525 - runtime/modules/ModuleStress/ModuleStressGC SIGSEGV in java_lang_String::is_instance(oop)
Duplicate :  
JDK-8210524 - runtime/modules/ModuleStress/ModuleStressGC.java test crashed
Relates :  
JDK-8210155 - Lock ClassLoaderDataGraph
Relates :  
JDK-8210524 - runtime/modules/ModuleStress/ModuleStressGC.java test crashed
Relates :  
JDK-8207024 - assert(check_klass_alignment(result)) failed: address not aligned: 0x00000008baadbabe
Description
Mach5 test failed:
open/test/hotspot/jtreg/runtime/modules/ModuleStress/ExportModuleStressTest.java

Snippet of test log:
----------System.err:(40/2495)----------
 stdout: [# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/klass.inline.hpp:66
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/scratch/opt/mach5/mesos/work_dir/slaves/c4ee7e63-1ded-4e8c-9581-ce26f27e3af4-S419/frameworks/14a03e04-9f3c-408e-8ddf-efd6aa9b759f-0005/executors/b85751ab-316e-4701-a0cd-9a949d51b4e8/runs/c13686f3-8a4b-415a-a724-6c31be32365b/workspace/open/src/hotspot/share/oops/klass.inline.hpp:66), pid=7666, tid=7769
#  assert(check_klass_alignment(result)) failed: address not aligned: 0x00000008baadbabe
#
# JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug build 12-internal+0-jdk12-jdk.345)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 12-internal+0-jdk12-jdk.345, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# 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:
# /scratch/opt/mach5/mesos/work_dir/slaves/c4ee7e63-1ded-4e8c-9581-ce26f27e3af4-S283473/frameworks/14a03e04-9f3c-408e-8ddf-efd6aa9b759f-0005/executors/b7220a9c-ee76-4b92-872c-3ccbf4c46b1c/runs/011cbdc7-290b-4fca-a931-7ae483696182/testoutput/jtreg/JTwork/scratch/0/hs_err_pid7666.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 7769
Dumping core ...
];
 stderr: []
 exitValue = 134

java.lang.RuntimeException: 'failed: 0' missing from stdout/stderr 

	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:150)
	at ExportModuleStressTest.main(ExportModuleStressTest.java:77)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:834)

JavaTest Message: Test threw exception: java.lang.RuntimeException: 'failed: 0' missing from stdout/stderr 

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'failed: 0' missing from stdout/stderr
Comments
The CLDG lock added between installing the CLD in the class_loader oop causes a safepoint. Concurrent callers can get the result of the class_loader.CLD before it was installed in the ClassLoaderDataGraph. I thought this was safe because following class_loader oop would follow the CLD, but it doesn't for young collections (or others). I moved the lock around the whole creation of the ClassLoaderData (and installing the names). Now the order of events is: Lock CLDG_lock NoSafepointVerifier Create ClassLoaderData Add ClassLoaderData to the graph Install ClassLoaderData into the class_loader oop (with store_release) ~NoSafepointVerifier // safepoints ok here Create Symbols for the ClassLoaderData name. Unlock CLDG_lock That way when thread 2 gets the class loader data name, with load_acquire, it is guaranteed to be added to the graph and safe for GC. There is code that tolerates that the name hasn't been updated yet for that window. Thanks to [~kbarrett] for finding the core file and walking through the details of this change with me.
10-09-2018
Stack: [0xffffffff37c00000,0xffffffff37d00000], sp=0xffffffff37cfbda0, free space=1007k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x20a3ee8] void VMError::report_and_die(int,const char*,const char*,void*,Thread*,unsigned char*,void*,void*,const char*,int,unsigned long)+0xa38 V [libjvm.so+0x20a343c] void VMError::report_and_die(Thread*,void*,const char*,int,const char*,const char*,void*)+0x3c V [libjvm.so+0xe9eb90] void report_vm_error(const char*,int,const char*,const char*,...)+0x80 V [libjvm.so+0x7c6a1c] Klass*Klass::decode_klass_not_null(unsigned)+0xdc V [libjvm.so+0x1f162d4] bool SystemDictionary::is_platform_class_loader(oop)+0x64 V [libjvm.so+0xcabae4] bool relax_format_check_for(ClassLoaderData*)+0x54 V [libjvm.so+0xcac408] ClassFileParser::ClassFileParser #Nvariant 1(ClassFileStream*,Symbol*,ClassLoaderData*,Handle,const InstanceKlass*,GrowableArray<Handle>*,ClassFileParser::Publicity,Thread*)+0x828 V [libjvm.so+0x189ef58] InstanceKlass*KlassFactory::create_from_stream(ClassFileStream*,Symbol*,ClassLoaderData*,Handle,const InstanceKlass*,GrowableArray<Handle>*,Thread*)+0x618 V [libjvm.so+0x1f1ac60] InstanceKlass*SystemDictionary::resolve_from_stream(Symbol*,Handle,Handle,ClassFileStream*,Thread*)+0x170 V [libjvm.so+0x14a3834] _jclass*jvm_define_class_common(JNIEnv_*,const char*,_jobject*,const signed char*,int,_jobject*,const char*,Thread*)+0x5c4 From hs_err_pid file. GC happened before CLD was added to CLDG and this thread is using a bad CLD.
07-09-2018
Probably unrelated to JDK-8207024. Looks like a regression from JDK-8210155. Shouldn't have put that ClassLoaderDataGraph_lock there. Loading the klass() field from a bad oop will get this same pattern, so it seems a generic failure mode with a GCed oop.
07-09-2018
Looks like this was previously seen in JDK-8207024
06-09-2018
Changed synopsis to reflect the fact it is an assertion failure. The RuntimeException information is not significant in relation to the actual failure cause.
05-09-2018
A crash in tier3 testing is surely a P2 initially!
05-09-2018
I added the failing assertion from the log file to the description. Not sure why that wasn't included.
05-09-2018