United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6268279 : Full GC causes core

Details
Type:
Bug
Submit Date:
2005-05-10
Status:
Resolved
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2005-07-26
Component:
hotspot
OS:
solaris
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2_09
Fixed Versions:
1.4.2_10 (b01)

Related Reports
Relates:
Relates:

Sub Tasks

Description
Initial description :
=======================

From ###@###.### Fri May  6 11:22:55 2005
Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.Central.Sun.COM [129.147.62.14])
	by swcms.Central.Sun.COM (8.11.7p1+Sun/8.11.6) with ESMTP id j46HMtN27570
	for <###@###.###>; Fri, 6 May 2005 11:22:55 -0600 (MDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j46HMseu024367
	for <###@###.###>; Fri, 6 May 2005 11:22:54 -0600 (MDT)
Received: from access1.central.sun.com (access1.Sun.COM [192.18.97.135])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j46HMsi7000297;
	Fri, 6 May 2005 11:22:54 -0600 (MDT)
Received: (from nobody@localhost)
	by access1.central.sun.com (8.11.7p1+Sun/8.11.6) id j46HJPi14235;
	Fri, 6 May 2005 11:19:25 -0600 (MDT)
Date: Fri, 6 May 2005 11:19:25 -0600 (MDT)
Message-Id: <###@###.###>
To: ###@###.###
Wrom: QKEDOTWFAOBUZXUWLSZLKBRNVW
CC: ###@###.###
Subject: Support Request
Reply-To: ###@###.###
Errors-To: ###@###.###

VERSION   ASKweb Version 3.0
REF       
PRIORITY  3
SECURITY  0
SYNOPSIS  Full GC causes core
BUG       
PLATFORM  
PRODUCT   J2SE 1.4.1_02 JVM
OS        Solaris/SunOS N/A N/A
CUST_NUM  75418
SERVERDOMAIN  NA
COUNTRY   USA
USERID    43000
CONTACT   Danny Hyun
COMPANY   Raining Data, Inc.
EMAIL     ###@###.###
PHONE     (949) 260-5187
CC        
MANAGER   
PATCH     0
DESCRIPTIONBEGIN
Serial Number: JS3909227991935996
Product Type : DS-Online Level 2
There are possibly two problems with the version of JDK that we're using (1.4.2_02 - I saw that this version was not available in the J2SE product description drop-down list) when running with the -server option under Solaris.

1. When an explicit System.gc() is called, we get a core dump.  When I take out the call to System.gc(), and I use either the default GC or the Parallel GC, the JVM core dumps at the first full GC (incremental GC works fine).  When I use the Concurrent GC, it seems that the JVM core dumps during the first incremental GC.

2. We might be running out of Perm Space.  We're not exactly sure about this since the first problem masks this issue, but we've seen in the past that the perm size does not get reclaimed.
DESCRIPTIONEND
TESTCASEBEGIN
Here are the snippets from the core as well as the output from -Xloggc:/tmp/gc.log.  The output was generated by running our server application without using any calls to System.GC.

***** Default GC *****

0.000: [GC 0.014: [DefNew: 329024K->7714K(339264K), 0.6314072 secs] 329024K->7714K(1038336K), 0.6319179 secs]
311.319: [GC 311.319: [DefNew: 336738K->1046K(339264K), 0.5394108 secs] 336738K->8251K(1038336K), 0.5397234 secs]
589.646: [GC 589.646: [DefNew: 330070K->1309K(339264K), 0.2729124 secs] 337275K->8514K(1038336K), 0.2732487 secs]
603.238: [Full GC 603.238: [Tenured

[Command-line Parameters]
-server -verbose:gc -Xloggc:/tmp/gc.log -XX:+PrintGCDetails -Xms1024m -Xmx1024m

[Core Stack Trace]
-----------------  lwp# 2 / thread# 2  --------------------
 ff31d998 _lwp_kill (6, 0, fc0fe820, 0, 23, ff00) + 8
 ff2b57b0 abort    (0, fc0fe8b0, 0, fffffff8, 0, fc0fe8d9) + 100
 ff098260 __1cCosFabort6Fi_v_ (1, ff15323a, fc0fe960, ff17e000, ff1c58bc, 3e93f4) + 80
 ff096574 __1cCosbBhandle_unexpected_exception6FpnGThread_ipCpv_v_ (0, b, fed0b18c, fc0ff6c8, fedd86c8, 0) + 2d4
 fedd8f9c JVM_handle_solaris_signal (fed0b18c, fc0ff6c8, fc0ff410, 3400, 35ec, 0) + 91c
 ff3860a0 __sighndlr (b, fc0ff6c8, fc0ff410, fedd864c, 0, 0) + c
 ff37fdd8 call_user_handler (b, fc0ff6c8, fc0ff410, 0, 0, 0) + 234
 ff37ff88 sigacthandler (b, fc0ff6c8, fc0ff410, 40, 0, 5d8064) + 64
 --- called from signal handler with signal 11 (SIGSEGV) ---
 fed0b18c __1cPVirtualCallDataPfollow_contents6M_v_ (5d80ac, 88, fc0ffc18, adc90, 446314, fed5f2b0) + 3c
 fed39c34 __1cPmethodDataKlassToop_follow_contents6MpnHoopDesc__v_ (f5c00b30, f65d0e00, b510, ff33a000, e738d8, e2ed
0) + fc
 fecd6278 __1cJMarkSweepLfollow_root6FppnHoopDesc__v_ (ff1ca880, ff1ca880, 0, ff33a000, 47c064, fed9ba80) + e0
 fee272cc __1cIUniverseHoops_do6FpnKOopClosure__v_ (ff1c2534, 1, fc0ff720, 0, 1, a3c0729) + 30
 fee25b84 __1cQGenCollectedHeapUprocess_strong_roots6Miiin0ATClassScanningOption_pnQOopsInGenClosure_3_v_ (ff17e000,
 ff1c2534, 0, 1, 2, ff1c2534) + 50
 fee62698 __1cMGenMarkSweepRmark_sweep_phase16Firii_v_ (1, fc0ffad4, 0, 45725c, fee61bf8, fc0ff35c) + dc
 fee61d20 __1cMGenMarkSweepTinvoke_at_safepoint6FipnSReferenceProcessor_i_v_ (ff1de644, 1cac490, 0, 4800, 5400, 5714
) + 20c
 fee63484 __1cbCOneContigSpaceCardGenerationHcollect6MiiIii_v_ (97a70, 1, 0, 0, 0, 0) + 38
 fee31b4c __1cQGenCollectedHeapNdo_collection6MiiIiiiri_v_ (0, ff1bd218, 0, 1, 0, ff17e000) + 520
 fee8bbb8 __1cQGenCollectedHeapSdo_full_collection6Miiri_v_ (96048, 0, 1, b1a7e32c, fa000000, 6) + 20
 fee2e3dc __1cMVM_OperationIevaluate6M_v_ (b1a7e310, 4400, ff17e000, 2cdf0, 4b42c8, fede1c34) + 8c
 fee2ddfc __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_ (e26c8, b1a7e310, 5000, 50dc, 5000, 0) + 84
 feef1e88 __1cIVMThreadEloop6M_v_ (4400, 4000, 4324, 4000, 42b0, 3800) + 3e8
 feef1984 __1cIVMThreadDrun6M_v_ (e26c8, 2, 40, 0, 40, 0) + 8c
 fee65600 _start   (e26c8, 0, 0, 0, 0, 0) + 134
 ff385d48 _lwp_start (0, 0, 0, 0, 0, 0)

***** Parallel GC *****

0.000: [GC 77407K->118066K(517632K), 0.2576409 secs]
0.258: [Full GC

[Command-Line Parameters]
-server -verbose:gc -XX:+UseParallelGC -XX:PermSize=128m -XX:MaxPermSize=245m -Xloggc:/tmp/gc.log -XX:+PrintGCDetails -Xms512m -Xmx512m

[Core Stack Trace]
-----------------  lwp# 3 / thread# 3  --------------------
 ff31d998 _lwp_kill (6, 0, fca7e518, 0, 1f, fca7e388) + 8
 ff2b57b0 abort    (0, fca7e590, 38, 0, 0, fca7e8a8) + 100
 c892be74 __default_terminate (e00, c89677d4, c892be70, 0, 1f, fca7eab8) + 4
 c892bea4 __terminate (0, fca7e8a8, 0, c866b848, c86a8d04, ffffffff) + 20
 c892c9bc throw_helper (0, ff3860a7, fca7ed58, 0, 0, 0) + 178
 c892cbc4 __throw  (7ea9e8, 2, 0, ffffffff, 5, c899a520) + 94
 c866b848 __SignalHandler__ (c89679e0, 0, fca7f6d0, 0, 0, 0) + 124
 ff3860a0 __sighndlr (a, 0, fca7f6d0, c866b724, 0, 0) + c
 ff37fdd8 call_user_handler (a, 0, fca7f6d0, 0, 0, 0) + 234
 ff37ff88 sigacthandler (a, 0, fca7f6d0, 40, 0, 11f6208) + 64
 --- called from signal handler with signal 10 (SIGBUS) ---
 fed0b18c __1cPVirtualCallDataPfollow_contents6M_v_ (11f6250, 88, fca7fcc8, 1d2ce8, 446314, fed5f2b0) + 3c
 fed39c34 __1cPmethodDataKlassToop_follow_contents6MpnHoopDesc__v_ (ea800b30, eb1cc758, fca7f898, 0, 1, 156fe051) + fc
 ff07b418 __1cJMarkSweepMfollow_stack6F_v_ (ff1c252c, 11a, 0, 1, 2b548, 64) + 5c
 ff0b146c __1cLPSMarkSweepRmark_sweep_phase16Frii_v_ (fca7fc64, 0, 1, 4314, 2bd40, d52a0000) + c8
 ff0b0c30 __1cLPSMarkSweepQinvoke_no_policy6Frii_v_ (ff1bd030, 0, ff1c60cc, ff1c60d4, ffbfd404, ff1ca978) + 444
 ff0b07b4 __1cLPSMarkSweepGinvoke6Frii_v_ (ffbfd404, 0, 1, ff17e000, 4266fbbb, fca7fd28) + 9c
 fee2e3dc __1cMVM_OperationIevaluate6M_v_ (ffbfd3e8, 4400, ff17e000, 2ce28, 4b42c8, fede1c34) + 8c
 fee2ddfc __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_ (2094e8, ffbfd3e8, 5000, 50dc, 5000, 0) + 84
 feef1e88 __1cIVMThreadEloop6M_v_ (4400, 4000, 4324, 4000, 42b0, 3800) + 3e8
 feef1984 __1cIVMThreadDrun6M_v_ (2094e8, 3, 40, 0, 40, 0) + 8c
 fee65600 _start   (2094e8, 0, 0, 0, 0, 0) + 134
 ff385d48 _lwp_start (0, 0, 0, 0, 0, 0)

***** Concurrent GC *****

0.000: [GC 0.023: [DefNew

[Command-line Parameters]
-server -verbose:gc -Xloggc:/tmp/gc.log -XX:+PrintGCDetails -XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewSize=192m -XX:MaxNewSize=192m -Xms512m -Xmx512m

[Core Stack Trace]
-----------------  lwp# 3 / thread# 3  --------------------
 ff31d998 _lwp_kill (6, 0, fca7dea8, 0, 1f, fca7dd18) + 8
 ff2b57b0 abort    (0, fca7df20, 38, 0, 0, fca7e238) + 100
 af62be74 __default_terminate (e00, af6677d4, af62be70, 0, 1f, fca7e448) + 4
 af62bea4 __terminate (0, fca7e238, 0, af36b848, af3a8d04, ffffffff) + 20
 af62c9bc throw_helper (0, ff3860a7, fca7e6e8, 0, 0, 0) + 178
 af62cbc4 __throw  (a9fd48, 2, 0, ffffffff, 5, af69a520) + 94
 af36b848 __SignalHandler__ (af6679e0, 0, fca7f060, 0, 0, 0) + 124
 ff3860a0 __sighndlr (a, 0, fca7f060, af36b724, 0, 0) + c
 ff37fdd8 call_user_handler (a, 0, fca7f060, 0, 0, 0) + 234
 ff37ff88 sigacthandler (a, 0, fca7f060, 341b, 0, 0) + 64
 --- called from signal handler with signal 10 (SIGBUS) ---
 fecc9988 __1cPFastScanClosureGdo_oop6MppnHoopDesc__v_ (fca7faa0, f65d06b4, fca7f610, f651f980, f5c00000, 79672c) + 24
 fede9078 __1cPVirtualCallDataNoop_iterate_m6MpnKOopClosure_nJMemRegion__v_ (796774, fca7f610, fca7f438, fca7f438, fc384e77, fca7f878) + 68
 fee57fd8 __1cPmethodDataKlassRoop_oop_iterate_m6MpnHoopDesc_pnKOopClosure_nJMemRegion__i_ (f5c00b30, f65d0608, fca7f610, fca7f4b8, fca7f520, f5c00b30) + 160
 fee57e68 __1cFKlassUoop_oop_iterate_nv_m6MpnHoopDesc_pnQFilteringClosure_nJMemRegion__i_ (f5c00b30, f65d0608, fca7f610, fca7f520, 81010100, ff00) + 30
 fef5603c __1cTFreeListSpace_DCTOCbDwalk_mem_region_with_cl_nopar6MnJMemRegion_pnIHeapWord_3pnQFilteringClosure__v_ (ca42b8, fca7f590, f65ced50, f65d2400, fca7f610, fca7f608
) + 130
 fef55d64 __1cTFreeListSpace_DCTOCXwalk_mem_region_with_cl6MnJMemRegion_pnIHeapWord_3pnQFilteringClosure__v_ (ca42b8, fca7f608, f65ced50, f65d2400, fca7f610, ca42b8) + 88
 fed05688 __1cPFiltering_DCTOCPwalk_mem_region6MnJMemRegion_pnIHeapWord_3_v_ (ca42b8, fca7f680, f65ced50, f65d2400, 150, 0) + 8c
 fed054d0 __1cVDirtyCardToOopClosureMdo_MemRegion6MnJMemRegion__v_ (ca42b8, fca7f6f0, 1, 4, 0, c1c15cf8) + 124
 fed05970 __1cYClearNoncleanCardWrapperMdo_MemRegion6MnJMemRegion__v_ (fca7f878, fca7f770, ff9d1e00, ffffffff, f5c00000, f6c00000) + f8
 fee278a4 __1cRCardTableModRefBSbBnon_clean_card_iterate_work6MnJMemRegion_pnQMemRegionClosure_i_v_ (ffffffff, 2, 10, 0, fc384e77, fca7f878) + 1c0
 fee27b74 __1cRCardTableModRefBSWnon_clean_card_iterate6MpnFSpace_nJMemRegion_pnVDirtyCardToOopClosure_pnQMemRegionClosure_i_v_ (96380, 9c6d0, fca7f870, ca42b8, fca7f878, 0)
 + 9c
 fee27a3c __1cLCardTableRSbDyounger_refs_in_space_iterate6MpnFSpace_pnQOopsInGenClosure__v_ (96378, 9c6d0, fca7faa0, f5c00000, 81010100, ff00) + 98
 fef6f318 __1cbDConcurrentMarkSweepGenerationUyounger_refs_iterate6MpnQOopsInGenClosure__v_ (9c5b8, fca7faa0, 2, ff17e000, fee16f50, fca7f2fc) + 50
 fee25d1c __1cQGenCollectedHeapUprocess_strong_roots6Miiin0ATClassScanningOption_pnQOopsInGenClosure_3_v_ (ff17e000, fca7fac4, 1, 0, 1, fca7faa0) + 1e8
 fee3a048 __1cQDefNewGenerationHcollect6MiiIii_v_ (b6710, 4800, 491c, fca7faa0, 962c0, ff1bb39c) + 3a8
 fee31b4c __1cQGenCollectedHeapNdo_collection6MiiIiiiri_v_ (c, ff1bd218, 0, 0, 0, ff17e000) + 520
 fee3a594 __1cbCTwoGenerationCollectorPolicyZsatisfy_failed_allocation6MIiiri_pnIHeapWord__ (962c0, 3, ff1bd218, 3c00, 3f74, ff17e000) + cc
 fee3a40c __1cbAVM_GenCollectForAllocationEdoit6M_v_ (ad77f4e4, fa0ad240, 1, ff17e000, a9da0, ff1c9680) + 18
 fee2e3dc __1cMVM_OperationIevaluate6M_v_ (ad77f4e4, 4400, ff17e000, 2d000, 4b42c8, fede1c34) + 8c
 fee2ddfc __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_ (ec0c8, ad77f4e4, 5000, 50dc, 5000, 0) + 84
 feef1e88 __1cIVMThreadEloop6M_v_ (4400, 4000, 4324, 4000, 42b0, 3800) + 3e8
 feef1984 __1cIVMThreadDrun6M_v_ (ec0c8, 3, 40, 0, 40, 0) + 8c
 fee65600 _start   (ec0c8, 0, 0, 0, 0, 0) + 134
 ff385d48 _lwp_start (0, 0, 0, 0, 0, 0)

TESTCASEEND
WORKAROUNDBEGIN


WORKAROUNDEND
COMMENTSBEGIN


COMMENTSEND
JUSTIFICATIONBEGIN

JUSTIFICATIONEND
TEMPLATEBEGIN

TEMPLATEEND
ESCALATIONEND

Reason for filing this Bug :
 We contacted Y.S. Ramakrishna for this issue and got the feedback from him that the fix applied to the Bug ID : 5015535 should be back ported to 1.4.2_09.
###@###.### 2005-05-10 23:04:18 GMT

that should read 1.4.2_XX, where XX is 09 or later depending on
how dates line up.
###@###.### 2005-05-19 23:02:58 GMT
###@###.### 2005-06-08 11:39:43 GMT

                                    

Comments
EVALUATION

 Initially evaluated by Y.S. Ramakrishna
###@###.### 2005-05-10 23:04:19 GMT

Not sure why a new CR was opened. Would a subCR for 5015535 not
have been sufficient for process purposes?

We will likely close this bug as a dup of 5015535 and transfer
this information to a subCR thereof. Note that 5015535
falls in hotspot/compiler2.

Also, Sreenatha informs me that the escalation associated with
this customer interaction in 1-8977791.
###@###.### 2005-05-14 00:19:56 GMT

The first step is to provide the customer with product and
debug binaries derived from 1.4.2 that fix the C2 bug 5015535.
It is expected that the customer will then be able to run long
enough to be able top demonstrate the perm space leak that they
think they are seeing (and which they believe is 4957990).
###@###.### 2005-05-17 20:24:02 GMT

Fastdebug build containing fix for C2 bug 5015535 shows arretion failure in verify_mdp().
---------------------------------------------
VM option '+VerifyBeforeGC'
VM option '+VerifyAfterGC'
VM option '+PrintHeapAtGC'
[Verifying threads permgen tenured generation def new generation remset syms strs zone dict hand C-heap ]
CompilerOracle: exclude com/rdta/server/common/UnmarshallingNodeOutputSequence storeAttribute
[Verifying threads permgen tenured generation def new generation remset syms strs zone dict hand C-heap ]

...

FAILED verify : actual mdp f5227d0c   expected mdp f5227d24 @ bci 39
  actual di 96   expected di 120
  actual bci is 36  expected bci 39
method data for {method} 'storeAttribute' '(Lcom/rdta/parser/nodes/AttributeMetaNode;)V' in 'com/rdta/server/common/UnmarshallingNodeOutputSequence'
0     bci: 4    BranchData          taken(1) displacement(24)
                                    not taken(0)
16    bci: 13   CounterData         count(0)
24    bci: 24   VirtualCallData     count(1) entries(1)
                                    'com/rdta/parser/nodes/AttributeMetaNode'(1)
48    bci: 27   VirtualCallData     count(1) entries(1)
                                    'com/rdta/server/common/Attribute'(1)
72    bci: 32   VirtualCallData     count(1) entries(1)
                                    'com/rdta/parser/nodes/AttributeMetaNode'(1)
96    bci: 36   VirtualCallData     count(0) entries(0)
120   bci: 39   BranchData          taken(0) displacement(68)
                                    not taken(0)
136   bci: 46   VirtualCallData     count(0) entries(0)
160   bci: 49   BitData             heroic_opt_failure_seen(false)
164   bci: 58   VirtualCallData     count(0) entries(0)
0 load_local_object #0
1 get_field 4 <m_currentAttribute>
4 branch_if_nonnull 19
  0   bci: 4    BranchData          taken(1) displacement(24)
                                    not taken(0)
7 load_local_object #0
8 new_object 78
11 dup
12 load_local_object #1
13 invoke_special 10 <<init>> <(Lcom/rdta/parser/nodes/AttributeMetaNode;)V>
  16  bci: 13   CounterData         count(0)
16 put_field 4 <m_currentAttribute>
19 load_local_object #0
20 get_field 4 <m_currentAttribute>
23 load_local_object #1
24 invoke_virtual 11 <getValue> <()Lcom/rdta/util/CharArrayReference;>
  24  bci: 24   VirtualCallData     count(1) entries(1)
                                    'com/rdta/parser/nodes/AttributeMetaNode'(1)
27 invoke_interface 12 <toString> <()Ljava/lang/String;> 1
  48  bci: 27   VirtualCallData     count(1) entries(1)
                                    'com/rdta/server/common/Attribute'(1)
32 invoke_virtual 13 <addValue> <(Ljava/lang/String;)V>
  72  bci: 32   VirtualCallData     count(1) entries(1)
                                    'com/rdta/parser/nodes/AttributeMetaNode'(1)
35 load_local_object #1
36 invoke_virtual 14 <isComplete> <()Z>
  96  bci: 36   VirtualCallData     count(0) entries(0)
39 branch_if_eq 66
  120 bci: 39   BranchData          taken(0) displacement(68)
                                    not taken(0)
42 load_local_object #0
43 get_field 3 <m_elementStack>
46 invoke_virtual 15 <peek> <()Ljava/lang/Object;>
  136 bci: 46   VirtualCallData     count(0) entries(0)
49 check_cast 106
  160 bci: 49   BitData             heroic_opt_failure_seen(false)
52 store_local_object #2
53 load_local_object #2
54 load_local_object #0
55 get_field 4 <m_currentAttribute>
58 invoke_virtual 16 <addAttribute> <(Lcom/rdta/server/common/Attribute;)V>
  164 bci: 58   VirtualCallData     count(0) entries(0)
61 load_local_object #0
62 push_object NULL
63 put_field 4 <m_currentAttribute>
66 return_void
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/interpreterRuntime.cpp:764]
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (/net/jpsesvr/export1/jpse/poonam/1.4.2_hotspot/src/share/vm/interpreter/interpreterRuntime.cpp, 764 [ Patched ]), pid=27343, tid=1
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2-bugfix-5015564-debug mixed mode)
#
# Error: assert(mdp == mdp2,"wrong mdp")
# An error report file with more information is saved as hs_err_pid27343.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 1
Dumping core ...
Abort - core dumped
---------------------------------------------------------------------

Customer has provided core file, which is present here:
/net/hanwka-home1.sfbay/global/export/home1/27/sd158479/rainingdata/

dbx session with the core file 'core-rdta-mem' can be started by running 'opencore' script present in the same folder.


Customer app runs fine with -Xint.




###@###.### 2005-06-08 11:39:44 GMT
                                     
2005-05-10
SUGGESTED FIX

The fix applied to Bug ID : 5015535 should be back ported to 1.4.2_09.
###@###.### 2005-05-10 23:04:19 GMT

that should read 1.4.2_XX, where XX is 09 or later depending on
how dates line up.
###@###.### 2005-05-19 23:02:58 GMT

Fixes 5015535/5015564 and 6261201 integrated in 1.4.2_10
http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=1515

###@###.### 2005-07-14 05:11:21 GMT
                                     
2005-05-10
WORK AROUND

No workaround.
###@###.### 2005-05-10 23:04:19 GMT

Workaround is to use -client so as not to run into
the core dump during GC or the perm space bloat
(both only seen with -server). However, this is not
viable because the performance of -client is not as
good as -server (when it works).
###@###.### 2005-05-17 20:22:09 GMT
                                     
2005-05-10



Hardware and Software, Engineered to Work Together