Bug ID: JDK-8276613 RunThese30M.java failed with "assert(check_alignment(result)) failed: address not aligned: 0x000000082d2d2d2d"

JDK-8276613 : RunThese30M.java failed with "assert(check_alignment(result)) failed: address not aligned: 0x000000082d2d2d2d"

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 18

Priority: P4
Status: Closed
Resolution: Cannot Reproduce
OS: windows
CPU: x86_64

Submitted: 2021-11-04
Updated: 2022-01-25
Resolved: 2022-01-25

Versions (Unresolved/Resolved/Fixed)

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 19
19Resolved

Related Reports

Duplicate :	JDK-8276614 - RunThese30M.java failed with "assert(check_alignment(result)) failed: address not aligned: 0x000000082d2d2d2d"
Relates :	JDK-8273108 - RunThese24H crashes with SEGV in markWord::displaced_mark_helper() after JDK-8268276
Relates :	JDK-8269633 - vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crashed with oopDesc::size_given_klass+0x6

Description

The following test failed in the JDK18 CI:

applications/runthese/RunThese30M.java

Here's a snippet from the log file:

Can't create EncryptedPrivateKeyInfo object for Cipher.PBEWithMD5AndTripleDES: java.security.NoSuchAlgorithmException: unrecognized algorithm name: PBEWithMD5AndTripleDES
Can't create EncryptedPrivateKeyInfo object for Cipher.PBEWithHmacSHA1AndAES_128: java.security.NoSuchAlgorithmException: unrecognized algorithm name: PBEWithHmacSHA1AndAES_128
Can't create EncryptedPrivateKeyInfo object for Cipher.PBEWithHmacSHA1AndAES_2#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (t:\\workspace\\open\\src\\hotspot\\share\\oops/compressedOops.inline.hpp:135), pid=67212, tid=5360
#  assert(check_alignment(result)) failed: address not aligned: 0x000000082d2d2d2d
#
# JRE version: Java(TM) SE Runtime Environment (18.0+22) (fastdebug build 18-ea+22-1415)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 18-ea+22-1415, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Core dump will be written. Default location: T:\\testoutput\\test-support\\jtreg_closed_test_hotspot_jtreg_applications_runthese_RunThese30M_java\\scratch\\0\\hs_err_pid67212.mdmp
#
# JFR recording file will be written. Location: T:\\testoutput\\test-support\\jtreg_closed_test_hotspot_jtreg_applications_runthese_RunThese30M_java\\scratch\\0\\hs_err_pid67212.jfr
#
Unsupported internal testing APIs have been used.

# An error report file with more information is saved as:
# T:\\testoutput\\test-support\\jtreg_closed_test_hotspot_jtreg_applications_runthese_RunThese30M_java\\scratch\\0\\hs_err_pid67212.log
[thread 42144 also had an error]
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(739/70550)*----------


Here's the crashing thread's stack:

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

Current thread (0x0000018e307dc2c0):  JavaThread "javasoft.sqe.tests.api.javax.crypto.EncryptedPrivateKeyInfo.GetKeySpec1Tests " daemon [_thread_in_Java, id=5360, stack(0x0000004a27700000,0x0000004a27800000)]

Stack: [0x0000004a27700000,0x0000004a27800000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xb55f51]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:235)
V  [jvm.dll+0xd9303e]  VMError::report+0x101e  (vmError.cpp:828)
V  [jvm.dll+0xd94a3e]  VMError::report_and_die+0x7fe  (vmError.cpp:1656)
V  [jvm.dll+0xd951c4]  VMError::report_and_die+0x64  (vmError.cpp:1437)
V  [jvm.dll+0x4df1b7]  report_vm_error+0xb7  (debug.cpp:282)
V  [jvm.dll+0x1e88f]  oopDesc::klass+0x9f  (oop.inline.hpp:85)
V  [jvm.dll+0x3cf39d]  CardTableBarrierSet::on_slowpath_allocation_exit+0x6d  (cardTableBarrierSet.cpp:130)
V  [jvm.dll+0xc19c35]  SharedRuntime::on_slowpath_allocation_exit+0x75  (sharedRuntime.cpp:3359)
V  [jvm.dll+0xc050b8]  OptoRuntime::new_array_C+0x318  (runtime.cpp:271)
C  0x0000018e5f2a5449

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::_new_array_Java
J 26637 c2 sun.security.provider.DigestBase.engineDigest()[B java.base@18-ea (33 bytes) @ 0x0000018e681f1c30 [0x0000018e681f1ac0+0x0000000000000170]
J 38972 c2 com.sun.crypto.provider.HmacCore.engineDoFinal()[B java.base@18-ea (78 bytes) @ 0x0000018e68f224f0 [0x0000018e68f22420+0x00000000000000d0]
J 38967 c2 javax.crypto.Mac.doFinal()[B java.base@18-ea (38 bytes) @ 0x0000018e68f1d7c4 [0x0000018e68f1d740+0x0000000000000084]
J 38954 c2 javax.crypto.Mac.doFinal([BI)V java.base@18-ea (65 bytes) @ 0x0000018e68f1c928 [0x0000018e68f1c7c0+0x0000000000000168]
J 38860 c2 com.sun.crypto.provider.PBKDF2KeyImpl.deriveKey(Ljavax/crypto/Mac;[B[BII)[B java.base@18-ea (295 bytes) @ 0x0000018e68efb250 [0x0000018e68efa280+0x0000000000000fd0]
j  com.sun.crypto.provider.PBKDF2KeyImpl.<init>(Ljavax/crypto/spec/PBEKeySpec;Ljava/lang/String;)V+183 java.base@18-ea
j  com.sun.crypto.provider.PBKDF2Core.engineGenerateSecret(Ljava/security/spec/KeySpec;)Ljavax/crypto/SecretKey;+31 java.base@18-ea
j  com.sun.crypto.provider.PBES2Core.engineInit(ILjava/security/Key;Ljava/security/spec/AlgorithmParameterSpec;Ljava/security/SecureRandom;)V+540 java.base@18-ea
j  com.sun.crypto.provider.PBES2Core.engineInit(ILjava/security/Key;Ljava/security/AlgorithmParameters;Ljava/security/SecureRandom;)V+37 java.base@18-ea
J 27237 c2 javax.crypto.Cipher.implInit(Ljavax/crypto/CipherSpi;IILjava/security/Key;Ljava/security/spec/AlgorithmParameterSpec;Ljava/security/AlgorithmParameters;Ljava/security/SecureRandom;)V java.base@18-ea (145 bytes) @ 0x0000018e682969e4 [0x0000018e682968e0+0x0000000000000104]
J 27212 c2 javax.crypto.Cipher.chooseProvider(IILjava/security/Key;Ljava/security/spec/AlgorithmParameterSpec;Ljava/security/AlgorithmParameters;Ljava/security/SecureRandom;)V java.base@18-ea (357 bytes) @ 0x0000018e6828e1f0 [0x0000018e6828dc40+0x00000000000005b0]
J 27315 c2 javax.crypto.Cipher.init(ILjava/security/Key;Ljava/security/AlgorithmParameters;Ljava/security/SecureRandom;)V java.base@18-ea (85 bytes) @ 0x0000018e67a39bb0 [0x0000018e67a39a20+0x0000000000000190]
J 37231 c2 javasoft.sqe.tests.api.javax.crypto.EncryptedPrivateKeyInfo.GetKeySpec1Tests.initCipher(ILjava/security/AlgorithmParameters;)Ljavax/crypto/Cipher; (78 bytes) @ 0x0000018e68cd902c [0x0000018e68cd8f60+0x00000000000000cc]
J 38457 c2 javasoft.sqe.tests.api.javax.crypto.EncryptedPrivateKeyInfo.GetKeySpec1Tests.testShouldBeSkiped()Z (189 bytes) @ 0x0000018e68e88608 [0x0000018e68e88460+0x00000000000001a8]
j  javasoft.sqe.jck.lib.ProviderTest.invokeTestCase(Ljava/lang/reflect/Method;)Ljavasoft/sqe/javatest/Status;+116
j  javasoft.sqe.javatest.lib.MultiTest.run([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;)Ljavasoft/sqe/javatest/Status;+139
J 34274 c1 javasoft.sqe.javatest.lib.MultiTest.run([Ljava/lang/String;Ljava/io/PrintStream;Ljava/io/PrintStream;)Ljavasoft/sqe/javatest/Status; (73 bytes) @ 0x0000018e6003d85c [0x0000018e6003bba0+0x0000000000001cbc]
J 34064 c1 javasoft.sqe.tests.api.javax.crypto.EncryptedPrivateKeyInfo.GetKeySpec1Tests.main([Ljava/lang/String;)V (23 bytes) @ 0x0000018e5ffdf79c [0x0000018e5ffdf2a0+0x00000000000004fc]
j  java.lang.invoke.LambdaForm$DMH+0x0000000800c03800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@18-ea
J 15372 c2 java.lang.invoke.LambdaForm$MH+0x0000000800c98400.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@18-ea (38 bytes) @ 0x0000018e67155ee0 [0x0000018e67155e20+0x00000000000000c0]
J 15342 c2 java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@18-ea (24 bytes) @ 0x0000018e6715d0c8 [0x0000018e6715cf60+0x0000000000000168]
J 26179 c2 jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@18-ea (92 bytes) @ 0x0000018e6817cee8 [0x0000018e6817cbe0+0x0000000000000308]
J 16482 c2 applications.kitchensink.process.stress.modules.JckStressModule$TestRunner$1.run()V (127 bytes) @ 0x0000018e674a8900 [0x0000018e674a86c0+0x0000000000000240]
v  ~StubRoutines::call_stub


Looks like we're crashing in C2 code so I'm starting this
bug off in hotspot/compiler for initial triage.

Comments

No failures with -XX:-UseTLAB. I vote for closing this as "Cannot Reproduce".
21-01-2022
I noticed the failure happened while allocating a new array on the slow path. This would make heap corruption more likely than on the fast path where a TLAB allocation does not have allocations from other threads nearby. I'm retrying Vladimir's test run with -XX:-UseTLAB.
21-01-2022
I run the test with the same JDK build but I did no hit any failures ;(
16-12-2021
Based on log the failure happened on 'avx512f avx512cd` Windows VM instance. It looks like KNL. The code fixed in JDK-8273108 is guarded by `supports_avx512bw` check. It seems it is different. On other hand hs_err file shows: CPU: total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 106 stepping 6 microcode 0x1, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512dq, avx512cd, avx512bw, avx512vl, sha, fma, vzeroupper, avx512_vpopcntdq, avx512_vpclmulqdq, avx512_vaes, avx512_vnni, clflush, clflushopt, clwb, avx512_vbmi2, avx512_vbmi, hv So may be it is related.
16-12-2021
It appears to have all the earmarks of the buffer overrun. Since this was filed in November, chances increase. I understand this is an intermittent error, but could someone re-run this with my fix applied?
16-12-2021
Based on the repeated 0x2d pattern, I'm wondering if this was caused by JDK-8273108. [~sgibbons], what do you think?
15-12-2021
ILW = intermittent crash in stress test on Windows = MLH = P4
05-11-2021
This might be related to JDK-8269633. There was a crash in vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java on Oct 16 with the same assert, it was on Windows, and both tests are doing class redefinition.
05-11-2021