JDK-8207024 : assert(check_klass_alignment(result)) failed: address not aligned: 0x00000008baadbabe
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 11
  • Priority: P2
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • Submitted: 2018-07-11
  • Updated: 2018-09-07
  • Resolved: 2018-08-13
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
11Resolved
Related Reports
Relates :  
JDK-8210457 - JVM crash in ResolvedMethodTable::add_method(Handle)
Relates :  
JDK-8210422 - runtime/modules/ModuleStress/ExportModuleStressTest.java - assertion failed: address not aligned: 0x00000008baadbabe
Description
Crash running compiler/codecache/stress/RandomAllocationTest.java:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (src/hotspot/share/oops/klass.inline.hpp:66), pid=26558, tid=42243
#  assert(check_klass_alignment(result)) failed: address not aligned: 0x00000008baadbabe
#
# JRE version: Java(TM) SE Runtime Environment (11.0) (fastdebug build 11-internal+0-jdk11-jdk.1032)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 11-internal+0-jdk11-jdk.1032, compiled mode, compressed oops, g1 gc, bsd-amd64)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Comments
The failure mode here seems the same as now reported in JDK-8210422.
06-09-2018
Unable to reproduce. Tried several hundred times initially, then 200 times specifically on same machine as the initial failure. Unfortunately, the same-machine attempts were after the same reboot that seemed to render JDK-8207163 no longer reproducible on that same machine, so no before/after reboot comparison for this one. And no core dump from the initial failure; one purpose of the reboot was to update the configuration to capture core dumps.
13-08-2018
from Kim: ... he bad value is the (decoded) klass pointer from an oop obtained from a WeakHandle (e.g. from an OopStorage)...
18-07-2018