JDK-7008136 : CMS: assert((HeapWord*)nextChunk <= _limit) failed: sweep invariant
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-12-20
  • Updated: 2011-04-23
  • Resolved: 2011-04-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.
Other JDK 6 JDK 7 Other
1.4.2_31,hs20Fixed 6u25Fixed 7Fixed hs20Fixed
Related Reports
Relates :  
Relates :  
Description
The nightly test:

runtime/ParallelClassLoading/std_CLs/URLClassLoader/forName/inner-complex

failed with the following assert:

;; Using jvm: "C:/local/common/jdk/baseline/windows-i586/jre/bin/server/jvm.dll"

Warning: This error log is *not* generated by the following JVM:
           C:/local/common/jdk/baseline/windows-i586/jre/bin/server/jvm.dll
         
         Expected vm_info: [Java HotSpot(TM) Server VM (20.0-b04-internal-201012161759.ysr.gc-merge-fastdebug) for windows-x86 JRE (1.7.0), built on Dec 16 2010 15:09:41 by "jprtadm" with unknown MS VC++:1600]
         Actual vm_info:   []
         
         JVM symbol lookup may be incorrect.
         Please use --jvm=<path/to/jvm> to point to the correct JVM.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (C:\temp\jprt\P1\B\175901.ysr\source\src\share\vm\gc_implementation\concurrentMarkSweep\concurrentMarkSweepGeneration.cpp:8110), pid=21568, tid=17992
#  assert((HeapWord*)nextChunk <= _limit) failed: sweep invariant
#
# JRE version: 7.0-b121
# Java VM: Java HotSpot(TM) Server VM (20.0-b04-internal-201012161759.ysr.gc-merge-fastdebug mixed mode windows-x86 )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Stack trace:

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

Current thread (0x00ae3400):  ConcurrentGCThread [stack: 0x00bc0000,0x00c10000] [id=17992]

Stack: [0x00bc0000,0x00c10000],  sp=0x00c0f9e4,  free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
Warning: This error log is *not* generated by the following JVM:
           C:/local/common/jdk/baseline/windows-i586/jre/bin/server/jvm.dll
         JVM symbol lookup may be incorrect.
         Please use --jvm=<path/to/jvm> to point to the correct JVM.

V  [jvm.dll+0x25862a];;  ?report_and_die@VMError@@QAEXXZ+0x54a
V  [jvm.dll+0x250be5];;  ?report_vm_error@@YAXPBDH00@Z+0x45
V  [jvm.dll+0x335f8c];;  ?doAlreadyFreeChunk@SweepClosure@@AAEXPAVFreeChunk@@@Z+0x17c
V  [jvm.dll+0x339a72];;  ?do_blk_careful@SweepClosure@@UAEIPAVHeapWord@@@Z+0xa2
V  [jvm.dll+0x32226e];;  ?blk_iterate_careful@CompactibleFreeListSpace@@QAEXPAVBlkClosureCareful@@@Z+0x2e
V  [jvm.dll+0x33481f];;  ?sweepWork@CMSCollector@@AAEXPAVConcurrentMarkSweepGeneration@@_N@Z+0x15f
V  [jvm.dll+0x338f72];;  ?sweep@CMSCollector@@QAEX_N@Z+0x312
V  [jvm.dll+0x33e8a3];;  ?collect_in_background@CMSCollector@@QAEX_N@Z+0x4c3
V  [jvm.dll+0x34125a];;  ?run@ConcurrentMarkSweepThread@@UAEXXZ+0x28a
C  [msvcr100.dll+0x5c6de]
C  [msvcr100.dll+0x5c788]
C  [kernel32.dll+0x4d0e9]
C  [ntdll.dll+0x419bb]
C  [ntdll.dll+0x4198e]

Current thread is:

=>0x00ae3400 (exited) ConcurrentGCThread [stack: 0x00bc0000,0x00c10000] [id=17992]

Heap:

Heap
 def new generation   total 14784K, used 7603K [0x04d00000, 0x05d00000, 0x05d00000)
  eden space 13184K,  55% used [0x04d00000, 0x05417578, 0x059e0000)
  from space 1600K,  21% used [0x059e0000, 0x05a35820, 0x05b70000)
  to   space 1600K,   0% used [0x05b70000, 0x05b70000, 0x05d00000)
 concurrent mark-sweep generation total 49152K, used 227K [0x05d00000, 0x08d00000, 0x0ad00000)
 concurrent-mark-sweep perm gen total 36080K, used 20662K [0x0ad00000, 0x0d03c000, 0x0ed00000)
runtime/ParallelClassLoading/std_CLs/PrivateMLet/forName/anonymous-complex

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-12-25/GC_Baseline-Xconc/vm/linux-i586/server/mixed/linux-i586_vm_server_mixed_vm.parallel_class_loading.testlist/analysis.html

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4947ee68d19c
07-01-2011

EVALUATION Note that although the assert, like the one in 6977970, has been recently uncovered, as of hs19b06, the bug itself is quite old, probably day-one, so needs to be backported to all the older rev's still in circulation. Also, as noted in the workaround section, the bug appears only when you have -Xms != -Xmx and the heap (old gen or per gen) is expanding during a collection cycle.
31-12-2010

EVALUATION As noted above, the fix for 6977970 had not been sufficiently diligent, so the full problem has not been completely solved with that fix. This could occasionally cause a portion of space, a prefix of a free block on one list to also appear on a different (smaller block size) list, allowing for double allocation and all kinds of heap corruption thereafter. The fix is for this terminal free block to be correctly coalesced and placed on the right list, rather than having part of its prefix stolen as can happen currently.
31-12-2010

SUGGESTED FIX Under test and review:- http://javaweb.sfbay.sun.com/~ysr/neeraja/export/ysr/hotspot-gc/webrev/
31-12-2010

WORK AROUND Same workaround as for 6977970:- Fixing the CMS generation sizes (by setting initial/min/max to the same value), so as to prevent genetration expansion, will avoid the assertion:- -Xms<n> -Xmx<n> -XX:PermSize=<m> -XX:MaxPermSize=<m>
29-12-2010

EVALUATION Related in spirit, if not in letter, to 6977970. The same logic that motivated 6977970 must be applied diligently to the sweep closure code where _limit is being used to drive decisions or to assert invariants.
29-12-2010