JDK-8068478 : SIGSEGV in CMS TestVirtualSpace::test()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • Submitted: 2015-01-05
  • Updated: 2015-01-26
  • Resolved: 2015-01-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.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Relates :  
Relates :  
Description
Crash occurred in GC nightlies.

The test was compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java

Stack:
C  [libc.so.1+0x5bff8]  strlen+0x18;;  strlen+0x18
V  [libjvm.so+0xa72820]  void report_vm_error(const char*,int,const char*,const char*)+0x38;;  __1cPreport_vm_error6Fpkci11_v_+0x38
V  [libjvm.so+0x15e201c]  void TestVirtualSpace_test()+0xdac;;  __1cVTestVirtualSpace_test6F_v_+0xdac
V  [libjvm.so+0xa1f74c]  CMSCollector::CMSCollector(ConcurrentMarkSweepGeneration*,CardTableRS*,ConcurrentMarkSweepPolicy*)+0x5fc;;  __1cMCMSCollector2t6MpnbDConcurrentMarkSweepGeneration_pnLCardTableRS_pnZConcurrentMarkSweepPolicy__v_+0x5fc
V  [libjvm.so+0xbf40e4]  bool GenCollectedHeap::create_cms_collector()+0xbc;;  __1cQGenCollectedHeapUcreate_cms_collector6M_b_+0xbc
V  [libjvm.so+0xbf0e84]  int GenCollectedHeap::initialize()+0x294;;  __1cQGenCollectedHeapKinitialize6M_i_+0x294
V  [libjvm.so+0x156e914]  int Universe::initialize_heap()+0x22c;;  __1cIUniversePinitialize_heap6F_i_+0x22c
V  [libjvm.so+0x156e164]  int universe_init()+0x84;;  __1cNuniverse_init6F_i_+0x84
V  [libjvm.so+0xc88fb4]  int init_globals()+0x114;;  __1cMinit_globals6F_i_+0x114
V  [libjvm.so+0x1531d38]  int Threads::create_vm(JavaVMInitArgs*,bool*)+0x290;;  __1cHThreadsJcreate_vm6FpnOJavaVMInitArgs_pb_i_+0x290
V  [libjvm.so+0xe79498]  JNI_CreateJavaVM+0xe0;;  JNI_CreateJavaVM+0xe0
C  [libjli.so+0x9d24]  InitializeJVM+0xfc;;  InitializeJVM+0xfc
C  [libjli.so+0x8184]  JavaMain+0x74;;  JavaMain+0x74
C  [libc.so.1+0xe24c4]  _lwp_start+0x8;;  _lwp_start+0x8


In the same batch the test closed/compiler/deoptimization/TestDoubleMerge.java got a SIGILL

Stack:
V  [libjvm.so+0x9a30e0]  void CollectedHeap::resize_all_tlabs()+0x0
V  [libjvm.so+0x13750fc]  bool PSScavenge::invoke()+0x16c
V  [libjvm.so+0x12e01b4]  HeapWord*ParallelScavengeHeap::failed_mem_allocate(unsigned long)+0x19c
V  [libjvm.so+0x15ecf74]  void VM_ParallelGCFailedAllocation::doit()+0x124
V  [libjvm.so+0x161aa7c]  void VM_Operation::evaluate()+0xf4
V  [libjvm.so+0x16167f0]  void VMThread::evaluate_operation(VM_Operation*)+0x248
V  [libjvm.so+0x1617234]  void VMThread::loop()+0x5e4
V  [libjvm.so+0x16162d4]  void VMThread::run()+0x124
V  [libjvm.so+0x12a0940]  java_start+0x378


Adding a link to a crash in PS old that was introduced in the same build. Different collectors and different tests, but I would say that these are too many crashes introduced in the same build to be unrelated.
Comments
Nothing was pushed to the GC repo over the holidays Dec 23 - Jan 02, so nine nightlies ran on the same build. These were fairly clean, a few known bugs showed up here and there, but nothing major. One night though (Dec 26) three tests crashed on the same machine in different tests running different GCs. Of course it is possible that some intermittent bug(s) decided to hit that night on that machine, but since none of these has reproduced since then I'm going to close this one as CNR and blame it on the machine for now. The later crash (in HeapChangeLogging.java) is from a different machine so I'll create a new bug for that one.
26-01-2015

None of these failures reproduces after a few days of running. The core in the first SIGSEGV didn't reveal anything except confirming that it is crashing in TestVirtualSpace_test() where it shouldn't even be executing since ExecuteInternalVMTests wasn't specified on the command line.
23-01-2015

Have been running these tests in a loop for ~2 hours now on sthsparc13.se.oracle.com now without any issues. This does not seem to be a common occurrence. (At the moment I cannot access the crash artifacts in aurora so I cannot analyze them).
08-01-2015

The stack trace for the crash in TestVirtualSpace_test() looks incorrect; that function should only be called when -XX:+ExecuteInternalVMTests appears on the command line.
06-01-2015

ILW = high (crash), low (one occurrence), high (no workaround) -> p2. No adjustment needed for the fact that this is a nightly testing failure; impact and workaround are already high.
06-01-2015

Another crash found in gc/defnew/HeapChangeLogging.java There is no hs_err.log for this crash. The log has: #0: [GC (Allocation Failure) 81920K->120831K(120832K), 16.4857013 secs] #1: [Full GC (Allocation Failure) 120831K->79927K(120832K), 3.4021796 secs] #2: [Full GC (Allocation Failure) 120831K->120827K(120832K), 0.4400766 secs] #3: [Full GC (Allocation Failure) 120831K->120811K(120832K), 0.3730115 secs] #4: [Full GC (Allocation Failure) 120831K->120831K(120832K), 0.3556132 secs] #5: [Full GC (Allocation Failure) 120831K->120831K(120832K), 0.3305079 secs] #6: [Full GC (Allocation Failure) 120831K->567K(120832K), 0.1332076 secs] # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xfffffd7ffe2d46e5, pid=29919, tid=5 #
05-01-2015