JDK-8058494 : nsk/stress/metaspace/jck60/jck60022 fails on windows with heap corruption
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2014-09-15
  • Updated: 2015-03-05
  • Resolved: 2015-03-05
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
Duplicate :  
Description
The test exits with status -1073740940, which is c0000374 (heap corruption) exception thrown by VC++ debug library

   JDK: Java(TM) SE Runtime Environment 1.9.0 b30 (1.9.0-ea-fastdebug-b30)
   VM: Java HotSpot(TM) Server VM 1.9.0 b0 (1.9.0-fastdebug-internal-201409122159.iklam.hs-merge-to-rt)
   Options: -server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M


===================================================
.../rt_baseline/windows-i586//bin/java -server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M -verify -XX:MaxMetaspaceSize=128m -XX:CompressedClassSpaceSize=64m -XX:MaxHeapSize=512m -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps nsk.stress.share.MetaspaceTestRunner -testList 
...
[2014-09-13T05:20:35.74] Stress time: 900 seconds
[2014-09-13T05:20:35.74] Iterations: 0
[2014-09-13T05:20:36.44] {Heap before GC invocations=1 (full 0):
[2014-09-13T05:20:36.44]  PSYoungGen      total 19200K, used 16640K [0x27d80000, 0x292c0000, 0x32800000)
[2014-09-13T05:20:36.44]   eden space 16640K, 100% used [0x27d80000,0x28dc0000,0x28dc0000)
[2014-09-13T05:20:36.44]   from space 2560K, 0% used [0x29040000,0x29040000,0x292c0000)
[2014-09-13T05:20:36.44]   to   space 2560K, 0% used [0x28dc0000,0x28dc0000,0x29040000)
[2014-09-13T05:20:36.44]  ParOldGen       total 43776K, used 0K [0x12800000, 0x152c0000, 0x27d80000)
[2014-09-13T05:20:36.44]   object space 43776K, 0% used [0x12800000,0x12800000,0x152c0000)
[2014-09-13T05:20:36.44]  Metaspace       used 4993K, capacity 5002K, committed 5120K, reserved 5504K


[2014-09-13T05:22:33.28] {Heap before GC invocations=112 (full 85):
[2014-09-13T05:22:33.28]  PSYoungGen      total 57600K, used 0K [0x27d80000, 0x2c100000, 0x32800000)
[2014-09-13T05:22:33.28]   eden space 46336K, 0% used [0x27d80000,0x27d80000,0x2aac0000)
[2014-09-13T05:22:33.28]   from space 11264K, 0% used [0x2aac0000,0x2aac0000,0x2b5c0000)
[2014-09-13T05:22:33.28]   to   space 11264K, 0% used [0x2b600000,0x2b600000,0x2c100000)
[2014-09-13T05:22:33.28]  ParOldGen       total 349696K, used 32141K [0x12800000, 0x27d80000, 0x27d80000)
[2014-09-13T05:22:33.28]   object space 349696K, 9% used [0x12800000,0x147636c0,0x27d80000)
[2014-09-13T05:22:33.28]  Metaspace       used 129466K, capacity 129818K, committed 131044K, reserved 131456K
[2014-09-13T05:22:33.40] 118.433: #111: [Full GC (Last ditch collection) [2014-09-13T05:22:33.40] # Test level exit status: -1073740940
===================================================

Comments
This has not been seen for a while, it may be a duplicate of JDK-8069282.
05-03-2015

I can't do anything with this. The exit could be the non-zero windows exit bug that happens to be something matching some heap monitoring exit value.
17-09-2014

Needs more information.
16-09-2014

Does this heap monitoring tool give a stack trace? jck60022 runs multiple JDK tests and could be native code error in the JDK. Or in the JCK test itself. Do we know if this is a JVM bug?
16-09-2014

More info about ExitCode -1073740940 aka 0xc0000374 http://blogs.msdn.com/b/jiangyue/archive/2010/03/16/windows-heap-overrun-monitoring.aspx
15-09-2014