The crash is intermittently seen in production by the customer running on Linux. It's been reported with both 6u2 as well as 6u5. The stack from hs_err follows:

Stack: [0x00000000,0x00000000], sp=0xb42d8300, free space=-1242272k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x24d99a];; oopDesc::size_given_klass(Klass*)+0x2a
V [libjvm.so+0x50bd7e];; ParScanClosure::do_oop_work(oopDesc**, bool, bool)+0x
7e
V [libjvm.so+0x50bbd6];; ParRootScanWithBarrierTwoGensClosure::do_oop(oopDesc*
*)+0x16
V [libjvm.so+0x34ec1e];; instanceKlass::oop_oop_iterate_nv_m(oopDesc*, Filteri
ngClosure*, MemRegion)+0x15e
V [libjvm.so+0x296285];; FreeListSpace_DCTOC::walk_mem_region_with_cl_par(MemR
egion, HeapWord*, HeapWord*, FilteringClosure*)+0xd5
V [libjvm.so+0x29617f];; FreeListSpace_DCTOC::walk_mem_region_with_cl(MemRegio
n, HeapWord*, HeapWord*, FilteringClosure*)+0x3f
V [libjvm.so+0x56f900];; Filtering_DCTOC::walk_mem_region(MemRegion, HeapWord*
, HeapWord*)+0x50
V [libjvm.so+0x56f74f];; DirtyCardToOopClosure::do_MemRegion(MemRegion)+0xcf
V [libjvm.so+0x24f73b];; ClearNoncleanCardWrapper::do_MemRegion(MemRegion)+0xa
b
V [libjvm.so+0x24e721];; CardTableModRefBS::non_clean_card_iterate_work(MemReg
ion, MemRegionClosure*, bool)+0x141
V [libjvm.so+0x5072ee];; CardTableModRefBS::process_stride(Space*, MemRegion,
int, int, DirtyCardToOopClosure*, MemRegionClosure*, bool, signed char**, unsign
ed, unsigned)+0xfe
V [libjvm.so+0x50718f];; CardTableModRefBS::par_non_clean_card_iterate_work(Sp
ace*, MemRegion, DirtyCardToOopClosure*, MemRegionClosure*, bool, int)+0xaf
V [libjvm.so+0x24e5ab];; CardTableModRefBS::non_clean_card_iterate(Space*, Mem
Region, DirtyCardToOopClosure*, MemRegionClosure*, bool)+0x4b
V [libjvm.so+0x24effc];; CardTableRS::younger_refs_in_space_iterate(Space*, Oo
psInGenClosure*)+0x5c
V [libjvm.so+0x32e51c];; Generation::younger_refs_in_space_iterate(Space*, Oop
sInGenClosure*)+0x1c
V [libjvm.so+0x2b3af0];; ConcurrentMarkSweepGeneration::younger_refs_iterate(O
opsInGenClosure*)+0x40
V [libjvm.so+0x24ef28];; CardTableRS::younger_refs_iterate(Generation*, OopsIn
GenClosure*)+0x28
V [libjvm.so+0x322b10];; GenCollectedHeap::gen_process_strong_roots(int, bool,
 bool, SharedHeap::ScanningOption(OopsInGenClosure*, void))+0x70
V [libjvm.so+0x509bc7];; ParNewGenTask::work(int)+0xc7
V [libjvm.so+0x5ffb63];; GangWorker::loop()+0xa3
V [libjvm.so+0x5ffa78];; GangWorker::run()+0x18
V [libjvm.so+0x4fde19];; java_start(Thread*)+0x139
C [libpthread.so.0+0x4dd8]

We've collected several hs_err logs from the customer and the stack seems very close in all of them.

The customer has tried the workaround mentioned in CR 6642634 of setting -Xmx == -Xms and -XX:PermSize == -XX:MaxPermSize but they still reported getting crashes.

We've asked the customer to try removing -XX:+UseBiasedLocking and to let us know whether or not they continue to see crashes.

Cu also reports that this application was stable running under 1.5.0_10.