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