JDK-8143546 : Test times out. VM appears to be blocked in GC
Type:Bug
Component:hotspot
Sub-Component:gc
Affected Version:9
Priority:P2
Status:Closed
Resolution:Duplicate
Submitted:2015-11-20
Updated:2015-11-23
Resolved:2015-11-23
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.
There are a lot of gc threads waiting here:
ffffffedc6fe34bc __1cYConcurrentG1RefineThreadbAwait_for_completed_buffers6M_v_ (10015c800, 15e0, ffffffedc8670498, 1400, 183c00, 1) + 74
Comments
The clue to this hang is in the debuggee pstack log (pstack.core.14720):
----------------- lwp# 2 / thread# 2 --------------------
ffffffff7eee6ad0 recv (6, ffffffff7dffeeb0, e, 0)
ffffffff7d30db28 recv (6, ffff7fff, e, 0, ffff7c00, 0) + 1c
fffffffcbe903750 dbgsysRecv (6, ffffffff7dffeeb0, e, 0, 0, 6) + 18
fffffffcbe902e14 recv_fully (6, ffffffff7dffeeb0, e, 6, e, 0) + 2c
fffffffcbe901f6c handshake (fffffffcbe903f90, 0, 0, fffffffcbea042e0, 6, ffffffff7dffeeb0) + e4
fffffffcbe902a74 socketTransport_attach (0, 100122b0a, 0, 0, fffffffcbea04830, fffffffcbe9028f0) + 184
fffffffcba332a80 transport_startTransport (0, 100122b00, 100122b0a, 0, fffffffcba4440a8, fffffffcba442d40) + 2c0
fffffffcba31a1e0 startTransport (100122c10, ffffffff7dfff748, c00, fffffffcba443960, fffffffcba442d40, fffffffcba33cf50) + 60
fffffffcba316dc0 bagEnumerateOver (100122ba0, fffffffcba31a180, ffffffff7dfff748, 18, 800, 0) + 30
fffffffcba31a958 initialize (10012ba40, 100594488, fffffffcba33d160, ffffffedc759d260, fffffffcba442d40, 13) + 380
fffffffcba319a40 cbEarlyVMInit (c00, 10012ba40, 100594488, fffffffcba33ccb0, fffffffcba442d40, 1) + e8
ffffffedc763459c __1cLJvmtiExportTpost_vm_initialized6F_v_ (0, ffffffedc8729258, 10012b800, ffffffedc8670498, ffffffedc81c29e9, 1001221d0) + 6dc
ffffffedc7bb6e48 __1cHThreadsJcreate_vm6FpnOJavaVMInitArgs_pb_i_ (10012b800, 0, 0, ffffffedc87054a1, 10012b800, ffffffedc8670498) + 870
ffffffedc745a9cc __1cWJNI_CreateJavaVM_inner6FppnHJavaVM__ppv3_i_ (ffffffff7dffff30, ffffffff7dffff28, ffffffff7dfffe58, 53d000, 1, ffffffedc8670498) + d4
ffffffedc880acec InitializeJVM (ffffffff7dffff30, ffffffff7dffff28, ffffffedc745ade0, 10000, 8, ffffffff7dfffe58) + f4
ffffffedc8809050 JavaMain (0, b10, 100106690, 100106ce0, ffffffedc8917770, 9) + 68
ffffffff7eee25b4 _lwp_start (0, 0, 0, 0, 0, 0)
This stack looked familiar and after searching for "post_vm_initialized"
test failures, I ran into this very old bug:
JDK-6303969 JDWP: Socket Transport handshake fails rarely on InstancesTest.java
https://bugs.openjdk.java.net/browse/JDK-6303969
I think this bug can be closed as a duplicate of JDK-6303969.
23-11-2015
That's normal that refinement threads are waiting on work to refinement. Also this is not the top-level stack entry, but the usual blocked on a mutex "fingerprint".