JDK-6530811 : regression b08: SEGV in FastScanClosure::do_oop
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6u3,6u4,7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux,windows_xp
  • CPU: generic,x86
  • Submitted: 2007-03-05
  • Updated: 2012-02-01
  • Resolved: 2011-03-08
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
6u4Fixed 7Fixed hs11Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  

Crashes with a SEGV:

Stack: [0xfc100000,0xfc180000),  sp=0xfc17f4a0,  free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x15c97c];;  void FastScanClosure::do_oop(oopDesc**)+0x38
V  [libjvm.so+0x48d1b8];;  void SystemDictionary::shared_oops_do(OopClosure*)+0x5c
V  [libjvm.so+0x4a8d78];;  void Universe::oops_do(OopClosure*,bool)+0x2c
V  [libjvm.so+0x457f40];;  void SharedHeap::process_strong_roots(bool,SharedHeap::ScanningOption,OopClosure*,OopsInGenClosure*)+0x6c
V  [libjvm.so+0x287c28];;  void GenCollectedHeap::gen_process_strong_roots(int,bool,bool,SharedHeap::ScanningOption,OopsInGenClosure*,OopsInGenClosure*)+0x38
V  [libjvm.so+0x264764];;  void DefNewGeneration::collect(bool,bool,unsigned,bool)+0x3fc
V  [libjvm.so+0x287510];;  void GenCollectedHeap::do_collection(bool,bool,unsigned,bool,int)+0x73c
V  [libjvm.so+0x230538];; HeapWord*GenCollectorPolicy::satisfy_failed_allocation(unsigned,bool)+0x194
V  [libjvm.so+0x15bea4];;  void VM_GenCollectForAllocation::doit()+0x9c
V  [libjvm.so+0x13dad8];;  void VM_Operation::evaluate()+0x88
V  [libjvm.so+0x4e613c];;  void VMThread::evaluate_operation(VM_Operation*)+0xd4
V  [libjvm.so+0x4e66cc];;  void VMThread::loop()+0x470
V  [libjvm.so+0xb526c];;  void VMThread::run()+0xa0
V  [libjvm.so+0x413f08];;  java_start+0x194

VM_Operation (0xfe77e4ec): generation collection for allocation, mode: safepoint, requested by thread 0x00031800

This seems to be a regression in b08. It occurs on all platforms and in both client and server VM - though client seems most common. Nightly failures in main/baseline trace back to around Feb 9. This failure doesn't seem to appear in other baselines.

SUGGESTED FIX /net/prt-archiver.sfbay/data/archived_workspaces/2007/20070709062415.jmasa.gc_baseline_6530811/ Webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/2007/20070709062415.jmasa.gc_baseline_6530811/workspace/webrevs/webrev-2007.07.09/index.html

EVALUATION This bug was introduced in the putback for 6516018. A method shared_oops_do() was created in SystemDictionary that scanned _int_mirror and friends that are part of the SystemDictionary. A call to shared_oops_do() was added to the Universe::oops_do() so that _int_mirror and friends would be scanned before _intArrayKlassObj (and friends). That ordering matters when class data sharing is being used. A call to shared_oops_do() was also made in SystemDictionary::preloaded_oops_do() at the original location where _int_mirror and friends were scanned. Removing the call to shared_oops_do() in SystemDictionary::preloaded_oops_do() fixes this bug. In general objects can only be scanned once. This bug was not more obvious because _int_mirror usually is not moved during a garbage collection and so scanning twice (both of which do nothing) was not a problem.