JDK-8248438 : SIGSEGV in ObjectMonitor::enter
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 16
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64
  • Submitted: 2020-06-28
  • Updated: 2020-10-08
  • Resolved: 2020-10-08
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 16
16Resolved
Related Reports
Duplicate :  
JDK-8248650 - [BACKOUT] Backout JDK-8244603 because it generates too much noise in CI
Duplicate :  
JDK-8254164 - G1 only removes self forwarding pointers for last collection set increment
Relates :  
JDK-8254164 - G1 only removes self forwarding pointers for last collection set increment
Relates :  
JDK-8253413 - [REDO] [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
Relates :  
JDK-8248447 - SIGSEGV in G1ScanHRForRegionClosure::scan_heap_roots
Relates :  
JDK-8249676 - [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
Relates :  
JDK-8253411 - [BACKOUT] [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
Description
The following test failed in the JDK16 CI:

applications/kitchensink/Kitchensink.java

Here's a snippet from the log file:

Iteration done: ThreadDumper at Sat Jun 27 19:42:13 UTC 2020
Iteration start: LockDeflation at Sat Jun 27 19:42:18 UTC 2020
Iteration done: SpecJbb2005 at Sat Jun 27 19:42:23 UTC 2020
Iteration start: SpecJbb2005 at Sat Jun 27 19:42:23 UTC 2020
Iteration done: LockDeflation at Sat Jun 27 19:42:56 UTC 2020
Iteration start: MemAccess at Sat Jun 27 19:43:11 UTC 2020
Iteration done: Allocator at Sat Jun 27 19:43:15 UTC 2020
Iteration start: Allocator at Sat Jun 27 19:43:15 UTC 2020
Iteration done: MemAccess at Sat Jun 27 19:44:11 UTC 2020
Compiled method (c2)  455862 19152   !   4       sun.nio.ch.FileChannelImpl$Closer::run (28 bytes)
 total in heap  [0x00007fa12da66410,0x00007fa12da678b0] = 5280
 relocation     [0x00007fa12da66568,0x00007fa12da665a0] = 56
 main code      [0x00007fa12da665a0,0x00007fa12da66f20] = 2432
 stub code      [0x00007fa12da66f20,0x00007fa12da66f48] = 40
 oops           [0x00007fa12da66f48,0x00007fa12da66f50] = 8
 metadata       [0x00007fa12da66f50,0x00007fa12da66f90] = 64
 scopes data    [0x00007fa12da66f90,0x00007fa12da671d0] = 576
 scopes pcs     [0x00007fa12da671d0,0x00007fa12da67880] = 1712
 dependencies   [0x00007fa12da67880,0x00007fa12da67898] = 24
 handler table  [0x00007fa12da67898,0x00007fa12da678b0] = 24


The tail of stress stdout is:
For random generator using seed: 4976682410192462535
To re-run test with same seed value please add "-Djdk.test.lib.random.seed=4976682410192462535" to command line.
Stress process main method is started.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fa14303b8ab, pid=4717, tid=4729
#
# JRE version: Java(TM) SE Runtime Environment (16.0+4) (build 16-ea+4-98)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16-ea+4-98, mixed mode, sharing, tiered, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xb208ab]  ObjectMonitor::enter(Thread*)+0x26b
#
# 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/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S227/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a9a4e078-02f5-4b44-9e6a-a89c7624241e/runs/c44a811c-a50d-40ae-840f-5ebd561d98ba/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/core.4717)
#
# JFR recording file will be written. Location: /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S227/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a9a4e078-02f5-4b44-9e6a-a89c7624241e/runs/c44a811c-a50d-40ae-840f-5ebd561d98ba/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/hs_err_pid4717.jfr
#
Unsupported internal testing APIs have been used.

# An error report file with more information is saved as:
# /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S227/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a9a4e078-02f5-4b44-9e6a-a89c7624241e/runs/c44a811c-a50d-40ae-840f-5ebd561d98ba/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/hs_err_pid4717.log
[thread 11945 also had an error]
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(178/17466)----------


Here's the crashing thread's stack:

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

Current thread (0x00007fa13c1ac0c0):  JavaThread "Finalizer" daemon [_thread_in_vm, id=4729, stack(0x00007fa124a1d000,0x00007fa124b1e000)]

Stack: [0x00007fa124a1d000,0x00007fa124b1e000],  sp=0x00007fa124b1c7d0,  free space=1021k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xb208ab]  ObjectMonitor::enter(Thread*)+0x26b
V  [libjvm.so+0xc98c6c]  ObjectSynchronizer::enter(Handle, BasicLock*, Thread*)+0xcc
V  [libjvm.so+0xbf96f0]  SharedRuntime::complete_monitor_locking_C(oopDesc*, BasicLock*, JavaThread*)+0x60

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::_complete_monitor_locking_Java
J 20526 c2 jdk.nio.zipfs.ZipFileSystem.close()V jdk.zipfs@16-ea (390 bytes) @ 0x00007fa12da331cc [0x00007fa12da30f60+0x000000000000226c]
J 52828 c2 jdk.nio.zipfs.ZipFileSystem.finalize()V jdk.zipfs@16-ea (5 bytes) @ 0x00007fa12c9c7db4 [0x00007fa12c9c7d80+0x0000000000000034]
J 45517% c2 java.lang.ref.Finalizer$FinalizerThread.run()V java.base@16-ea (56 bytes) @ 0x00007fa12e458420 [0x00007fa12e457e60+0x00000000000005c0]
v  ~StubRoutines::call_stub

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000000001af
Comments
Closing this issue as a duplicate of JDK-8254164 because this failure follows from G1 leaving a bad mark word after gc. Also during development of JDK-8254164 this crash happened a lot.
08-10-2020
The frequency of this bug's failure mode increased when the following was integrated in the jdk-16+16-678 build-ID: JDK-8249676 [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
21-09-2020
Stack-trace: #43 <signal handler called> #44 0x00007fc000830965 in CompressedKlassPointers::decode_raw (v=<error reading variable: Cannot access memory at address 0x230000000000000e>) at /opt/mach5/mesos/work_dir/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S2395/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ 66fa7d4d-544b-4219-bf01-2f23563432ea/runs/fb014d91-04f7-476c-880e-a7e041819881/workspace/open/src/hotspot/share/oops/compressedOops.hpp:167 #45 CompressedKlassPointers::decode_not_null (v=<error reading variable: Cannot access memory at address 0x230000000000000e>) at /opt/mach5/mesos/work_dir/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S2395/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ 66fa7d4d-544b-4219-bf01-2f23563432ea/runs/fb014d91-04f7-476c-880e-a7e041819881/workspace/open/src/hotspot/share/oops/compressedOops.inline.hpp:85 #46 oopDesc::klass (this=0x2300000000000006) at /opt/mach5/mesos/work_dir/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S2395/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ 66fa7d4d-544b-4219-bf01-2f23563432ea/runs/fb014d91-04f7-476c-880e-a7e041819881/workspace/open/src/hotspot/share/oops/oop.inline.hpp:93 #47 ObjectMonitor::enter (this=0x7de46ae11, __the_thread__=__the_thread__@entry=0x7fbff81ae950) at /opt/mach5/mesos/work_dir/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S2395/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ 66fa7d4d-544b-4219-bf01-2f23563432ea/runs/fb014d91-04f7-476c-880e-a7e041819881/workspace/open/src/hotspot/share/runtime/objectMonitor.cpp:314 #48 0x00007fc0009a7c4c in ObjectSynchronizer::enter (obj=..., lock=lock@entry=0x7fbf99dc2900, __the_thread__=__the_thread__@entry=0x7fbff81ae950) at /opt/mach5/mesos/work_dir/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S2395/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ 66fa7d4d-544b-4219-bf01-2f23563432ea/runs/fb014d91-04f7-476c-880e-a7e041819881/workspace/open/src/hotspot/share/runtime/synchronizer.cpp:601 #49 0x00007fc000909a00 in SharedRuntime::monitor_enter_helper (thread=0x7fbff81ae950, lock=0x7fbf99dc2900, obj=0x7de46ae10) at /opt/mach5/mesos/work_dir/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S2395/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ 66fa7d4d-544b-4219-bf01-2f23563432ea/runs/fb014d91-04f7-476c-880e-a7e041819881/workspace/open/src/hotspot/share/runtime/sharedRuntime.cpp:2086 #50 SharedRuntime::complete_monitor_locking_C (obj=0x7de46ae10, lock=0x7fbf99dc2900, thread=0x7fbff81ae950) at /opt/mach5/mesos/work_dir/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S2395/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ 66fa7d4d-544b-4219-bf01-2f23563432ea/runs/fb014d91-04f7-476c-880e-a7e041819881/workspace/open/src/hotspot/share/runtime/sharedRuntime.cpp:2093 #51 0x00007fbfe0d0e3ad in ?? ()
28-08-2020
The monitor looks like rubbish: $1 = {_header = {_value = 9367487225062639278, static age_bits = 4, static lock_bits = 2, static biased_lock_bits = 1, static max_hash_bits = 57, static hash_bits = 31, static unused_gap_bits = 1, static epoch_bits = 2, static lock_shift = 0, static biased_lock_shift = 2, static age_shif t = 3, static unused_gap_shift = 7, static hash_shift = 8, static epoch_shift = 8, static lock_mask = 3, static lock_mask_in_place = 3, static biased_lock_mask = 7, static biased_lock_mask_in_place = 7, static biased_lock_bit_in_place = 4, static age_mask = 15, static age_mask_in_place = 120, static epoch_mask = 3, static epoch_mask_in_place = 768, static hash_mask = 2147483647, static hash_mask_in_place = 549755813632, static biased_lock_alignment = 2048, static locked_value = 0, static unlocked_value = 1, static monitor_value = 2, static marked_value = 3, static biased_lock_pattern = 5, static no_hash = 0, static no_hash_in_place = 0, static no_lock_in_place = 1, static max_age = 15, static max_bias_epoch = 3}, _object = 0x2300000000000006, _allocation_state = (ObjectMonitor::Old | unknown: 132007596), _pad_buf0 = "\000\000\000\206\245\026\000\000\000\000\000\000\000\000\000\307\325\310\373;\256F\336\a\000\000\000M\t\000\000\002", '\000' <repea ts 11 times>, _owner = 0x5b00000000000000, _previous_owner_tid = -9079256848646912338, _pad_buf1 = "\006\000\000\000\000\000\000k\256F\336\a\000\000\000k\246\026\000\000\000\000\000\373=\t\312\a\000\000\000��\026\000\264\325\310\373 c=\t\312\a\000\000\000\005", _next_om = 0xd5fbc8d5b90005a1, _recursions = 5012542, _EntryList = 0x77fbc9bfe7000000, _cxq = 0xcf4c7c5d12fbc8c8, _succ = 0x100000000fbc8d5, _Responsible = 0x9000000000000000, _Spinner = -2147483640, _SpinDuration = 1308622848, _contentions = 1870099558, _WaitSet = 0x746172756769666e, _waiters = 778989417, _WaitSetLock = 1935764579, static _sync_ContendedLockAttempts = 0x7fbff8042510, static _sync_FutileWakeups = 0x7fbff8042670, static _sync_Parks = 0x7fbff80427d0, static _sync_Notifications = 0x7fbff8042920, static _sync_Inflations = 0x7fbff8041b40, static _sync_Deflations = 0x7fbff80423c0, static _sync_MonExtant = 0x7fbff8042a80, static Knob_SpinLimit = 5000}
28-08-2020
I got this crash last week, so it's still present.
27-08-2020
This failure mode has not been seen since the following was pushed in jdk-16+8-299: JDK-8250644 Disable debugger in kitchensink tests so it is possible that the reappearance of this failure mode after: JDK-8248650 [BACKOUT] Backout JDK-8244603 because it generates too much noise in CI was pushed in jdk-16+5-161 is related to the 'debugger' module. The 'debugger' module was enabled via: JDK-8249248 Re-enable debugger in kitchensink tests which was pushed in jdk-16+6-204 and there are only two failures since that push. Reminder: absence of proof is not proof of absence!
04-08-2020
Here's a snippet from the log file for the jdk-16+7-232-tier8 failure: For random generator using seed: -7565047940853626915 To re-run test with same seed value please add "-Djdk.test.lib.random.seed=-7565047940853626915" to command line. Stress process main method is started. [4962.359s][warning][gc] GC locker is held; pre-dump GC was skipped [6696.811s][warning][gc] GC locker is held; pre-dump GC was skipped [14077.533s][warning][gc] GC locker is held; pre-dump GC was skipped [14947.812s][warning][gc] GC locker is held; pre-dump GC was skipped [18428.534s][warning][gc] GC locker is held; pre-dump GC was skipped [39713.217s][warning][gc] GC locker is held; pre-dump GC was skipped [44059.508s][warning][gc] GC locker is held; pre-dump GC was skipped [49709.506s][warning][gc] GC locker is held; pre-dump GC was skipped [60581.266s][warning][gc] GC locker is held; pre-dump GC was skipped [64059.814s][warning][gc] GC locker is held; pre-dump GC was skipped [68843.587s][warning][gc] GC locker is held; pre-dump GC was skipped [69277.426s][warning][gc] GC locker is held; pre-dump GC was skipped [72751.692s][warning][gc] GC locker is held; pre-dump GC was skipped [75796.484s][warning][gc] GC locker is held; pre-dump GC was skipped [81449.752s][warning][gc] GC locker is held; pre-dump GC was skipped [83188.123s][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=0x00007f0bf2904985, pid=29509, tid=29521 # # JRE version: Java(TM) SE Runtime Environment (16.0+7) (build 16-ea+7-232) # Java VM: Java HotSpot(TM) 64-Bit Server VM (16-ea+7-232, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xb2b985][thread 5211 also had an error][thread 5208 also had an error][thread 1295 also had an error][thread 29554 also had an error] [thread 1294 also had an error] ObjectMonitor::enter(Thread*)+0x135 # # 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/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S48/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ec322515-6359-4a46-90ad-47398c59ccb5/runs/e93edf8e-a0a2-4769-957a-422c80ac51dc/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/core.29509) # # JFR recording file will be written. Location: /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S48/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ec322515-6359-4a46-90ad-47398c59ccb5/runs/e93edf8e-a0a2-4769-957a-422c80ac51dc/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/hs_err_pid29509.jfr # Unsupported internal testing APIs have been used. # An error report file with more information is saved as: # /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S48/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ec322515-6359-4a46-90ad-47398c59ccb5/runs/e93edf8e-a0a2-4769-957a-422c80ac51dc/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/hs_err_pid29509.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ----------System.err:(978/80399)---------- Here's the crashing thread's stack: --------------- T H R E A D --------------- Current thread (0x00007f0bec1adac0): JavaThread "Finalizer" daemon [_thread_in_vm, id=29521, stack(0x00007f0bac97f000,0x00007f0baca80000)] Stack: [0x00007f0bac97f000,0x00007f0baca80000], sp=0x00007f0baca7e840, free space=1022k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xb2b985] ObjectMonitor::enter(Thread*)+0x135 V [libjvm.so+0xca1f7c] ObjectSynchronizer::enter(Handle, BasicLock*, Thread*)+0xcc V [libjvm.so+0xc041e0] SharedRuntime::complete_monitor_locking_C(oopDesc*, BasicLock*, JavaThread*)+0x60 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~RuntimeStub::_complete_monitor_locking_Java J 7608203 c2 jdk.nio.zipfs.ZipFileSystem.close()V jdk.zipfs@16-ea (390 bytes) @ 0x00007f0be308d3a8 [0x00007f0be308b800+0x0000000000001ba8] J 7608098 c2 jdk.nio.zipfs.ZipFileSystem.finalize()V jdk.zipfs@16-ea (5 bytes) @ 0x00007f0bdefa8a34 [0x00007f0bdefa8a00+0x0000000000000034] J 207206% c2 java.lang.ref.Finalizer$FinalizerThread.run()V java.base@16-ea (56 bytes) @ 0x00007f0bdd737c90 [0x00007f0bdd7378e0+0x00000000000003b0] v ~StubRoutines::call_stub siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000000001af
23-07-2020
So this issue is sometimes SI_KERNEL and sometimes a normal SEGV: siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000000001af I have to suspect that the underlying problem is deletion/modification of a memory mapped file whilst still in use - a failure in a finalizer is always suspect in relation to how it may race with other actions.
21-07-2020
Here's a snippet from the log file for the jdk-16+7-224-tier8 failure: Output and diagnostic info for process 8240 was saved into 'pid-8240-output.log' [2020-07-19T22:23:21.227993377Z] Gathering output for process 8243 [2020-07-19T22:23:27.433962279Z] Waiting for completion for process 8243 [2020-07-19T22:23:27.434013916Z] Waiting for completion finished for process 8243 Output and diagnostic info for process 8243 was saved into 'pid-8243-output.log' [stress.process.out] # [stress.process.out] # A fatal error has been detected by the Java Runtime Environment: [stress.process.out] # [stress.process.out] # SIGSEGV (0xb) at pc=0x00007f1453dc0e45, pid=9528, tid=9540 [stress.process.out] # [stress.process.out] # JRE version: Java(TM) SE Runtime Environment (16.0+7) (build 16-ea+7-224) [stress.process.out] # Java VM: Java HotSpot(TM) 64-Bit Server VM (16-ea+7-224, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) [stress.process.out] # Problematic frame: [stress.process.out] # V [libjvm.so+0xb2be45] ObjectMonitor::enter(Thread*)+0x135 [stress.process.out] # [stress.process.out] # 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/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S47/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/bb34a1ec-1cff-43ba-826b-923706aa0f87/runs/112541bc-caca-493e-a777-5c4ee72b7fe4/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/core.9528) [stress.process.out] # [stress.process.out] # JFR recording file will be written. Location: /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S47/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/bb34a1ec-1cff-43ba-826b-923706aa0f87/runs/112541bc-caca-493e-a777-5c4ee72b7fe4/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/hs_err_pid9528.jfr [stress.process.out] # [stress.process.out] Unsupported internal testing APIs have been used. [stress.process.out] [stress.process.out] # An error report file with more information is saved as: [stress.process.out] # /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S47/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/bb34a1ec-1cff-43ba-826b-923706aa0f87/runs/112541bc-caca-493e-a777-5c4ee72b7fe4/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java/scratch/0/hs_err_pid9528.log [stress.process.out] # [stress.process.out] # If you would like to submit a bug report, please visit: [stress.process.out] # https://bugreport.java.com/bugreport/crash.jsp [stress.process.out] # [2020-07-19T22:24:27.438635380Z] Gathering output for process 8410 [2020-07-19T22:24:27.450992120Z] Waiting for completion for process 8410 [2020-07-19T22:24:27.451049668Z] Waiting for completion finished for process 8410 Output and diagnostic info for process 8410 was saved into 'pid-8410-output.log' [2020-07-19T22:24:27.453248924Z] Gathering output for process 8414 [2020-07-19T22:24:33.636352643Z] Waiting for completion for process 8414 [2020-07-19T22:24:33.636406765Z] Waiting for completion finished for process 8414 Here's the crashing thread's stack: --------------- T H R E A D --------------- Current thread (0x00007f144c1ada70): JavaThread "Finalizer" daemon [_thread_in_vm, id=9540, stack(0x00007f145028c000,0x00007f145038d000)] Stack: [0x00007f145028c000,0x00007f145038d000], sp=0x00007f145038b780, free space=1021k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xb2be45] ObjectMonitor::enter(Thread*)+0x135 V [libjvm.so+0xca252c] ObjectSynchronizer::enter(Handle, BasicLock*, Thread*)+0xcc V [libjvm.so+0xc04790] SharedRuntime::complete_monitor_locking_C(oopDesc*, BasicLock*, JavaThread*)+0x60 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~RuntimeStub::_complete_monitor_locking_Java J 4803128 c2 java.nio.channels.spi.AbstractInterruptibleChannel.close()V java.base@16-ea (37 bytes) @ 0x00007f143f6b8488 [0x00007f143f6b7bc0+0x00000000000008c8] J 19129 c2 jdk.nio.zipfs.ZipFileSystem.close()V jdk.zipfs@16-ea (390 bytes) @ 0x00007f143d8f5150 [0x00007f143d8f4c60+0x00000000000004f0] J 75372 c2 jdk.nio.zipfs.ZipFileSystem.finalize()V jdk.zipfs@16-ea (5 bytes) @ 0x00007f143d652234 [0x00007f143d652200+0x0000000000000034] J 134371% c2 java.lang.ref.Finalizer$FinalizerThread.run()V java.base@16-ea (56 bytes) @ 0x00007f143deb7f10 [0x00007f143deb7b60+0x00000000000003b0] v ~StubRoutines::call_stub siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000 We have another instance of the SI_KERNEL issue.
20-07-2020
This bug was originally closed as a duplicate of: JDK-8248650 [BACKOUT] Backout JDK-8244603 because it generates too much noise in CI and that fix was integrated into jdk-16+05 which corresponds to jdk-16+5-161. We have another instance of a SIGSEGV in ObjectMonitor::enter() in jdk-16+7-224-tier8 so I'm reopening this bug and assigning it to myself.
20-07-2020
This failure mode has not reproduced since Thomas pushed: JDK-8248650 [BACKOUT] Backout JDK-8244603 because it generates too much noise in CI This bug can be closed as a duplicate of JDK-8248650 at Thomas's discretion.
06-07-2020
Investigating all the failure logs shows that all have an evacuation failure before that crashing gc. This seems to be a pre-existing bug (with evacuation failure?) as JDK-8244603 only changed young gen sizing. Assigning to me for further investigation.
01-07-2020
ILW = HLM = P3
30-06-2020
It looks like I have this failure mode narrowed down to jdk-16+4-82. That build ID includes just two changesets: 2020-06-25 14:07 tschatzl: 8c2040 - OpenJDK 8243672 Short term pause time ratio calculation in G1 off 2020-06-25 14:07 tschatzl: 0f2ac2 - OpenJDK 8244603 G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs I've constructed a repo at the fix for 8243672 and I'm kicking off a Tier8.
30-06-2020
jdk-16+4-81 does not reproduce this failure mode and is the last build ID before the Tier1 Win* breakages were introduced. jdk-16+4-88 reproduces this failure mode and it is the first build ID after the second Tier1 Win* breakage was fixed. This means that what ever introduced this breakage happened between jdk-16+4-82 -> jdk-16+4-88.
29-06-2020
Do these tests utilise async exceptions in any way - either via Thread.stop (or JVM TI equivalent) or using memory mapped bytebuffers that might lead to async "unsafe access errors"? We have identified problems with async exception handling code in relation to interpreter counter overflow checks that seem to be being exposed due to a reduced number of safepoints occurring these days
28-06-2020
The original Tier8 testing that I did for JDK-8246477 was using a repo that was baselined on jdk-16+1: $ hg log -r tip; hg -R open log -r qparent changeset: 30647:97654967210f tag: tip user: lmesnik date: Thu Jun 11 15:59:53 2020 -0700 summary: 8246710: Kitchensink: Instrumentation module fails to instrument classes which throw errors in clinit changeset: 59756:4a485c89d5a0 tag: qparent user: darcy date: Thu Jun 11 16:35:29 2020 -0700 summary: 8247374: Remove default constructors from javax.net.sslK When I pushed the fix for JDK-8246477, it just missed the snapshot for jdk-16+3 and was included in the JDK16 CI in jdk-16+3-77. I don't have Tier8 results for that build ID. The next Tier8 to include those changes is jdk-16+4-94-tier8 which includes some of the (confidential) sightings above.
28-06-2020
Async Monitor Deflation was pushed in jdk-15+26 via: JDK-8153224 Monitor deflation prolong safepoints and we have not seen these kinds of crashing in the JDK15 CI. I recently pushed the following fix to JDK16: JDK-8246477 add whitebox support for deflating idle monitors and jdk-16+4-94-tier8 is the first Tier8 since the bits were pushed. I'm going to take a closer look at the fix for JDK-8246477. I just checked my tracker for this bug and I did run Mach5 Tier[1-8] on this fix. No signs of these SIGSEGV crashes in any of the tiers...
28-06-2020