JDK-8274343 : Kitchensink8H.java fails with SIGSEGV in MemAccessWorkerThread
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 18
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2021-09-27
  • Updated: 2021-11-03
  • Resolved: 2021-11-03
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
18Resolved
Related Reports
Duplicate :  
JDK-8274340 - [BACKOUT] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references
Relates :  
JDK-8274340 - [BACKOUT] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references
Description
The following test failed in the JDK18 CI:

applications/kitchensink/Kitchensink8H.java

Here's a snippet from the log file:

The tail of stress stdout is:
For random generator using seed: -7885897026634313525
To re-run test with same seed value please add "-Djdk.test.lib.random.seed=-7885897026634313525" to command line.
Stress process main method is started.
[7581.340s][warning][gc] GC locker is held; pre-dump GC was skipped
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000001b8e5894855, pid=23101, tid=32647
#
# JRE version: Java(TM) SE Runtime Environment (18.0+17) (build 18-ea+17-965)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (18-ea+17-965, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# Problematic frame:
# C  0x000001b8e5894855
#
# Core dump will be written. Default location: core.23101
#
# JFR recording file will be written. Location: /System/Volumes/Data/mesos/work_dir/slaves/ff806ead-2cac-495d-9cbc-62116f99bf14-S25226/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e10dd6f1-8de7-415c-af83-148d99df00fb/runs/1d8d0032-87c4-4535-bd6f-e3512a28d057/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink8H_java/scratch/0/hs_err_pid23101.jfr
#
Unsupported internal testing APIs have been used.

# An error report file with more information is saved as:
# /System/Volumes/Data/mesos/work_dir/slaves/ff806ead-2cac-495d-9cbc-62116f99bf14-S25226/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e10dd6f1-8de7-415c-af83-148d99df00fb/runs/1d8d0032-87c4-4535-bd6f-e3512a28d057/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink8H_java/scratch/0/hs_err_pid23101.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(884/76804)----------


Here's the crashing thread's stack:

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

Current thread (0x00007fdc2690f610):  JavaThread "MemAccessWorkerThread" [_thread_in_Java, id=32647, stack(0x000070000f33d000,0x000070000f43d000)]

Stack: [0x000070000f33d000,0x000070000f43d000],  sp=0x000070000f43c5d8,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x000001b8e5894855


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000001b8e5894855

I don't have any good indicators where to drop this bug so
I'm sending it to hotspot/runtime for initial triage.
Comments
I think closing as dup sounds good.
02-11-2021
Last occurrence of this issue has been with build 974. Unless somebody objects I will close this one as duplicate of JDK-8274340 (in build 1015) soon - the build without that fix is so broken that any run with verification will crash on that; verification of JDK-8274340 and JDK-8274516 which redid this change (correctly this time) running Kitchensink more than thousand times without crash. Further, given Ioi's findings, both this stack trace and the other relates to java.lang.ref.ReferenceQueue too, giving strong suspicion about the causation.
02-11-2021
[~iklam]: sorry, I overlooked your comment. Yeah, if there are java.lang.ref.References involved, there is a high likelihood that this is the issue caused by JDK-8271880. This problem is so frequent when trying to reproduce with verification, that it will likely overshadow any other issues until after the build that contains JDK-8274340 (build 1015) (I'm getting 90% failure rate of kitchensink with verification because of that).
07-10-2021
Here's a log file snippet for the the jdk-18+17-974-tier8 sighting: The tail of stress stdout is: For random generator using seed: -5530941159990427365 To re-run test with same seed value please add "-Djdk.test.lib.random.seed=-5530941159990427365" to command line. Stress process main method is started. [6566.635s][warning][gc] GC locker is held; pre-dump GC was skipped # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f354d3e839a, pid=13463, tid=3830 # # JRE version: Java(TM) SE Runtime Environment (18.0+17) (build 18-ea+17-974) # Java VM: Java HotSpot(TM) 64-Bit Server VM (18-ea+17-974, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # J 3806 c2 java.lang.ref.ReferenceQueue.reallyPoll()Ljava/lang/ref/Reference; java.base@18-ea (65 bytes) @ 0x00007f354d3e839a [0x00007f354d3e8320+0x000000000000007a] # # Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/ff806ead-2cac-495d-9cbc-62116f99bf14-S13812/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d55e5362-3386-4539-909a-bdcbad901a49/runs/a5e03f91-7108-441d-a068-3d0e973dc99e/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/core.13463) # # JFR recording file will be written. Location: /opt/mach5/mesos/work_dir/slaves/ff806ead-2cac-495d-9cbc-62116f99bf14-S13812/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d55e5362-3386-4539-909a-bdcbad901a49/runs/a5e03f91-7108-441d-a068-3d0e973dc99e/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/hs_err_pid13463.jfr # Unsupported internal testing APIs have been used. # An error report file with more information is saved as: # /opt/mach5/mesos/work_dir/slaves/ff806ead-2cac-495d-9cbc-62116f99bf14-S13812/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d55e5362-3386-4539-909a-bdcbad901a49/runs/a5e03f91-7108-441d-a068-3d0e973dc99e/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/hs_err_pid13463.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ----------System.err:(784/69877)---------- Here's the crashing thread's stack: --------------- T H R E A D --------------- Current thread (0x00007f348c8cdbb0): JavaThread "MemAccessWorkerThread" [_thread_in_Java, id=3830, stack(0x00007f3474eb8000,0x00007f3474fb9000)] Stack: [0x00007f3474eb8000,0x00007f3474fb9000], sp=0x00007f3474fb7560, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 3806 c2 java.lang.ref.ReferenceQueue.reallyPoll()Ljava/lang/ref/Reference; java.base@18-ea (65 bytes) @ 0x00007f354d3e839a [0x00007f354d3e8320+0x000000000000007a] J 1723 c2 java.lang.invoke.MethodType$ConcurrentWeakInternSet.get(Ljava/lang/Object;)Ljava/lang/Object; java.base@18-ea (47 bytes) @ 0x00007f354d2b87a0 [0x00007f354d2b8180+0x0000000000000620] J 1096491 c2 java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; java.base@18-ea (109 bytes) @ 0x00007f354fe2f5e0 [0x00007f354fe2f540+0x00000000000000a0] J 11049 c2 java.lang.invoke.VarHandle$AccessType.accessModeType(Ljava/lang/Class;Ljava/lang/Class;[Ljava/lang/Class;)Ljava/lang/invoke/MethodType; java.base@18-ea (219 bytes) @ 0x00007f354d31041c [0x00007f354d30fca0+0x000000000000077c] J 93525 c2 java.lang.invoke.VarHandleFloats$FieldInstanceReadOnly.accessModeTypeUncached(Ljava/lang/invoke/VarHandle$AccessType;)Ljava/lang/invoke/MethodType; java.base@18-ea (16 bytes) @ 0x00007f354d4543c4 [0x00007f354d454320+0x00000000000000a4] J 5423 c2 java.lang.invoke.VarHandle.getMethodHandleUncached(I)Ljava/lang/invoke/MethodHandle; java.base@18-ea (86 bytes) @ 0x00007f354d561b74 [0x00007f354d561540+0x0000000000000634] J 10949 c2 applications.kitchensink.process.stress.modules.MemAccessStressModule.testFloatField(Ljava/lang/invoke/VarHandle;Ljava/lang/Object;I)V (180 bytes) @ 0x00007f354dadfcc8 [0x00007f354dadf660+0x0000000000000668] J 84709 c2 java.lang.Thread.run()V java.base@18-ea (17 bytes) @ 0x00007f354f0e5ad8 [0x00007f354f0e5820+0x00000000000002b8] v ~StubRoutines::call_stub V [libjvm.so+0x7c4be5] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x315 V [libjvm.so+0x7c63db] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x1cb V [libjvm.so+0x88d94a] thread_entry(JavaThread*, JavaThread*)+0x8a V [libjvm.so+0xd41802] JavaThread::thread_main_inner()+0xc2 V [libjvm.so+0xd456f0] Thread::call_run()+0xc0 V [libjvm.so+0xbab221] thread_native_entry(Thread*)+0xe1 siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000872616883
05-10-2021
[~tschatzl] could you check if this has the same cause as JDK-8274340? There's no stack in the hs_err file. However, one of the register is a java.lang.ref.ReferenceQueue. It also happens that the hs_err in JDK-8274340 also has a ReferenceQueue in one of its registers. I tentatively assigned the bug to GC. Please assign back to runtime if you think the issues are unrelated.
29-09-2021
ILW = HLM = P3
28-09-2021