JDK-6736295 : SIGSEGV in product jvm, assertion "these are the only valid states during a mark sweep" in fastdebug
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs14
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-08-12
  • Updated: 2010-04-03
  • Resolved: 2009-02-13
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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
JDK-6539517 - CR 6186200 should be extended to perm gen allocation to prevent spurious OOM's from perm gen
Relates :  
JDK-6723160 - Nightly failure: Error: meet not symmetric
Relates :  
JDK-6782457 - CMS: Livelock in CompactibleFreeListSpace::block_size().
Relates :  
JDK-6186200 - RFE: Stall allocation requests while heap is full and GC locker is held
Relates :  
JDK-6736203 - PIT: HS14-b03 crashes during intensive class loading
Relates :  
JDK-6789220 - CMS: intermittent timeout running nsk/regression/b4796926
Relates :  
JDK-6618936 - serial gc crash in ContiguousSpace::prepare_for_compaction
Description
Product jvm crashes with SIGSEGV, fastdebug jvm fails with assertion:

Internal Error (/tmp/jprt-jprtadm/P2/B/111010.ap154020/source/src/share/vm/memory/space.cpp:430), pid=27742, tid=3
Error: assert(!true || oop(q)->mark()->is_marked() || oop(q)->mark()->is_unlocked() || oop(q)->mark()->has_bias_pattern(),
              "these are the only valid states during a mark sweep")
Java VM: OpenJDK Client VM (14.0-b01-2008-08-07-111010.ap154020.hotspot-fastdebug compiled mode solaris-x86 )
Comments
SUGGESTED FIX http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d249b360e026
13-12-2008
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d249b360e026
11-12-2008
EVALUATION This and CR 6782457 have the same root cause, so they will both be fixed by the following:- 6782457: CMS: Livelock in CompactibleFreeListSpace::block_size() 6736295: SIGSEGV in product jvm, assertion "these are the only valid states during a mark sweep" in fastdebug webrev: http://analemma.sfbay/net/neeraja/export/ysr/gclocker/webrev Despite the synopsis, 6782457 turned out to be more than just a CMS-only livelock. Because of the need to parse cards while allocating into them, CMS expects transiently uninitialized but eventually initialized storage. In this case, there was a mutator thread that blocked at a GC-safepoint while holding on to uninitialized storage, so we got into a livelock in CMS with the VM/GC thread busy-waiting for the storage to be initialized. The basic problem is that we cannot have uninitialized storage for any of our current GC's, but some code restructuring while implementing 6539517 inadvertently broke that invariant. In particular, CR 6736295, which can currently affect any of the SerialGC, CMS or G1, is also a result of this bug. The simple fix is to restructure the (locking in the) code in the perm gen allocation retry loop to avoid such blocking. Many thanks to Jon for first finding this bug and, he and John for ongoing testing help as well. Testing: jck12a017 from CR 6736295; jprt; other testing in progress
11-12-2008
EVALUATION I can reproduce the failure on sparc with a fastdebug client VM and this command line: $ java -fastdebugclient -showversion -XX:+UseSerialGC -XX:MaxPermSize=12288k nsk.stress.jck12a.jck12a017.jck12a017 -stress:verbose -stress:indulgent It usually fails within 1-3 iterations. hg bisect says this changeset introduced the failure: changeset: 103:c0492d52d55b parent: 77:d05ebaf00ed0 user: apetrusenko date: Tue Apr 01 15:13:47 2008 +0400 summary: 6539517: CR 6186200 should be extended to perm gen allocation to prevent spurious OOM's from perm gen We're scanning the perm gen and run into 0xbaadbabe: # Internal Error (/tmp/jprt-jprtadm/P2/B/111010.ap154020/source/src/share/vm/memory/space.cpp:430), pid=11859, tid=3 # Error: assert(!true || oop(q)->mark()->is_marked() || oop(q)->mark()->is_unlocked() || oop(q)->mark()->has_bias_pattern(),"these are the only valid states during a mark sweep") Heap def new generation total 4544K, used 18K [0xf3200000, 0xf36e0000, 0xf36e0000) eden space 4096K, 0% used [0xf3200000, 0xf32049e0, 0xf3600000) from space 448K, 0% used [0xf3670000, 0xf3670000, 0xf36e0000) to space 448K, 0% used [0xf3600000, 0xf3600000, 0xf3670000) tenured generation total 60544K, used 50389K [0xf36e0000, 0xf7200000, 0xf7200000) the space 60544K, 83% used [0xf36e0000, 0xf6815780, 0xf6816800, 0xf7200000) compacting perm gen total 12288K, used 12287K [0xf7200000, 0xf7e00000, 0xfb200000) the space 12288K, 99% used [0xf7200000, 0xf7dfffc0, 0xf7e00000, 0xf7e00000) dbx t@3 l@3 9> print q q = 0xf77fffe0 dbx t@3 l@3 13> x q / 8 0xf77fffe0: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xf77ffff0: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe dbx t@3 l@3 19> x q-16 / 24 0xf77fffa0: 0x00000001 0xf6c00f40 0x00000001 0xf71b7260 0xf77fffb0: 0x00000005 0x00000000 0x00000000 0x00000000 0xf77fffc0: 0x00000001 0xf6c00f40 0x00000001 0xf6f07320 0xf77fffd0: 0x0000000b 0x00000000 0x00000000 0x00000000 0xf77fffe0: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xf77ffff0: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe dbx t@3 l@3 20> x 0xf6f07320 / 8 0xf6f07320: 0x00000001 0xf6c00ec8 0xf6f07370 0xf77fffc0 0xf6f07330: 0xf6f07460 0x0000000d 0x00000000 0x00000000
23-09-2008