JDK-8322163 : runtime/Unsafe/InternalErrorTest.java fails on Alpine after JDK-8320886
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 22,23
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux_alpine
  • CPU: x86
  • Submitted: 2023-12-15
  • Updated: 2024-03-12
  • Resolved: 2023-12-22
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 22 JDK 23
22Fixed 23 b04Fixed
Related Reports
Relates :  
JDK-8320886 - Unsafe_SetMemory0 is not guarded
Relates :  
JDK-8327885 - runtime/Unsafe/InternalErrorTest.java enters endless loop on Alpine aarch64
Description
We notice these crashes on Alpine Linux, maybe related to JDK-8320886.
test runtime/Unsafe/InternalErrorTest.java crashes on Alpine (works fine on other test OS/CPU platforms) :

#
# SIGSEGV (0xb) at pc=0x00007fd3c080064f, pid=7075, tid=7161
#
# JRE version: OpenJDK Runtime Environment (23.0) (build 23-internal-adhoc.jenkinsi.jdk)
# Java VM: OpenJDK 64-Bit Server VM (23-internal-adhoc.jenkinsi.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C [ld-musl-x86_64.so.1+0x5464f] memset+0xa7
#

backtrace :
Stack: [0x00007fd35ceff000,0x00007fd35cfffa90], sp=0x00007fd35cffeb28, free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [ld-musl-x86_64.so.1+0x5464f] memset+0xa7
j jdk.internal.misc.Unsafe.setMemory0(Ljava/lang/Object;JJB)V+0 java.base@23-internal
j jdk.internal.misc.Unsafe.setMemory(Ljava/lang/Object;JJB)V+25 java.base@23-internal
j jdk.internal.misc.ScopedMemoryAccess.setMemoryInternal(Ljdk/internal/foreign/MemorySessionImpl;Ljava/lang/Object;JJB)V+17 java.base@23-internal
j jdk.internal.misc.ScopedMemoryAccess.setMemory(Ljdk/internal/foreign/MemorySessionImpl;Ljava/lang/Object;JJB)V+8 java.base@23-internal
j jdk.internal.foreign.AbstractMemorySegmentImpl.fill(B)Ljava/lang/foreign/MemorySegment;+30 java.base@23-internal
j InternalErrorTest.test(Ljava/nio/MappedByteBuffer;Ljdk/internal/misc/Unsafe;JJI)V+105
j InternalErrorTest.main([Ljava/lang/String;)V+231
j java.lang.invoke.LambdaForm$DMH+0x00007fd363002000.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@23-internal
j ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????+33 java.base@23-internal
j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base@23-internal
j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base@23-internal
j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@23-internal
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base@23-internal
j com.sun.javatest.regtest.agent.MainWrapper$MainTask.run()V+134
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@23-internal
j java.lang.Thread.run()V+19 java.base@23-internal
v ~StubRoutines::call_stub 0x00007fd3aef6bcc4
V [libjvm.so+0x91e91b] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x2db (javaCalls.cpp:415)
V [libjvm.so+0x920282] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x1c2 (javaCalls.cpp:329)
V [libjvm.so+0xa0390c]
[error occurred during error reporting (printing native stack (with source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fd3c07d2b8e]
Comments
But JDK-8320886 was backported to JDK 22 back on Dec 13, before this issue was even created. So this issue was a candidate for 23 and 22 - no need for 22u in between. But what is done is done.
11-01-2024
Why was this backported to 22u and 22?
10-01-2024
Hi David, we see the issue in our jdk22 tests too (because https://bugs.openjdk.org/browse/JDK-8320886 triggering this is now in 22 as well). That's why I requested the jdk22u fix.
10-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22/pull/43 Date: 2024-01-09 13:33:49 +0000
09-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22u/pull/8 Date: 2024-01-05 09:23:29 +0000
05-01-2024
jdk22u backport request I would like to backport the patch to jdk22u because the issue is present there too. The backport is clean and low-to-medium risk
05-01-2024
When the Copy::fill_to_bytes(dst, size, value) - call at the end of Copy::fill_to_memory_atomic https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/copy.cpp#L246 is replaced by a for loop for (uintptr_t off = 0; off < size; off += sizeof(jbyte)) { *(volatile jbyte*)(dst + off) = fill; } (seems the volatile is needed by avoid silent replacement/optimization of gcc by using memset) , the test passes nicely on Alpine. So the 'surprising' signal seems to occur only with memset.
28-12-2023
Changeset: 12308533 Author: Matthias Baesken <mbaesken@openjdk.org> Date: 2023-12-22 13:30:05 +0000 URL: https://git.openjdk.org/jdk/commit/1230853343c38787c90820d19d0626f0c37540dc
22-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17175 Date: 2023-12-21 09:12:33 +0000
21-12-2023