Solaris JDK 1.4.2_18, Solaris Sparc 10

*Description*
Customer (running WebSphere with a bundled Solaris JDK ) is experiencing an
apparent object corruption situation that they believe that is much like
Sunbug 6344991 (which is marked as a duplicate of 6322757). 6322757 is
fixed in JDK 1.4.2_12. Howevever, one of the crashing servers is running
1.4.2_18.

*Detail*
The crashes have occurred every 2-4 weeks. The crashes have occurred on 5
different servers, two different hardware platforms, two different JVM
versions (including the latest), and before/after the OS patches.

The applications are memory intensive. They do hit fragmentation/compaction.
The applications barely fits in the 4GB process and IBM has had to scale
vertically several times.

The issue has occurred in development, staging (perf), and production.
The crashes have ocurred on multiples version of the customer's appliation.
Typically the systems are stressed. However, they have also seen the crash
in development, which is not stressed.

*Crash Output*

See Comments section for pointer to output.

*Thread Stack*
> > ----------------- lwp# 22 / thread# 22 --------------------
> > ff2caa58 _lwp_kill (6, 0, ff342f98, fecbdb8c, ffffffff, 6) + 8
> > ff24194c abort (fed9bee0, 1, fed24278, fcb78, ff3413d8, 0) + 110
> > fecbdb8c __1cCosFabort6Fi_v_ (1, fed859ad, 1, 80808080, ff0000,
> > 80808080) + 54
> > fed24278 __1cHVMErrorOreport_and_die6M_v_ (fed9bee0, fed9beef,
> > fed9beff, fecc8788, f807f580, f807f2c8) + 980
> > fe9dae84 JVM_handle_solaris_signal (b, fecc8788, fed854b1, 1, fdeca200,
> > f807f2c8) + a18
> > ff2c6e78 __sighndlr (b, f807f580, f807f2c8, fe9da438, 0, 1) + c
> > ff2bb558 call_user_handler (b, ffbffeff, c, 0, fdeca200, f807f2c8) +
> > 3b8
> > ff2bb72c sigacthandler (b, f807f580, f807f2c8, f807fc4c, fdeca200,
> > fe994b14) + 4c
> > --- called from signal handler with signal 11 (SIGSEGV) ---
> > fecc8788 __1cbGParRootScanWithoutBarrierClosureGdo_oop6MppnHoopDesc__v_
> > (f807fc4c, 4717e87c, 1c, 2, 17, 476f18) + 30
> > fe994b14
> > __1cJOopMapSetGall_do6FpknFframe_pnICodeBlob_pknLRegisterMap_pnKOopClosu
> > re_pFppnHoopDesc_9E_v9B9B_v_ (10, e9e90, f807f838, f807fc4c, fea9bf38,
> > fede84b8) + 6c0
> > fe994ce4
> > __1cJOopMapSetHoops_do6FpknFframe_pnICodeBlob_pknLRegisterMap_pnKOopClos
> > ure__v_ (f807f828, fa83a688, f807f838, f807fc4c, 40cd54, fe95d084) + 40
> > fe95d0c0 __1cFframeHoops_do6MpnKOopClosure_pnLRegisterMap__v_
> > (f807f828, f807fc4c, f807f838, 1, 1, 1) + a8
> > fe9a3900 __1cKJavaThreadHoops_do6MpnKOopClosure__v_ (d891698, f807fc4c,
> > 1, 0, 1, f807fc28) + 13c
> > fed068d0 __1cHThreadsZpossibly_parallel_oops_do6FpnKOopClosure__v_
> > (f807fc4c, 1, ff000001, ff000001, 46c0, 1) + ec
> > fea27b28
> > __1cQGenCollectedHeapUprocess_strong_roots6Miiin0ATClassScanningOption_p
> > nQOopsInGenClosure_3_v_ (feda0000, f807fc4c, 1, 0, 1, f807fc28) + 94
> > fecc7ec8 __1cNParNewGenTaskEwork6Mi_v_ (67b7fa80, 11, ff000001,
> > ff000001, 46c0, 1) + 3d8
> > fed280c4 __1cKGangWorkerDrun6M_v_ (e9df0, 16, 40, 0, 40, 0) + ac
> > fecbd130 java_start (e9df0, f8080000, 0, 0, fecbcffc, 1) + 134
> > ff2c6d4c _lwp_start (0, 0, 0, 0, 0, 0)


TEST CASE
---------
No testcase is available for recreation.

WORKAROUND
----------
No known workaround.