Customer application running under WAS 4 experiences
regular restarts due to JVM crashes.
The crashes are always very similar, with pstack traces for the failing
thread looking like this:
ff369764 __sigprocmask (ff36bf60, 0, 0, ceb81d70, ff37e000, 0) + 8
ff35e110 _sigon (ceb81d70, ff385930, 6, ceb80254, ceb81d70, 6) + d0
ff361150 _thrp_kill (0, 163, 6, ff37e000, 163, ff2c0450) + f8
ff24ba1c raise (6, 0, 0, ffffffff, ff2c03bc, 4) + 40
ff23593c abort (ff2bc004, ceb803a8, 0, fffffff8, 4, ceb803c9) + 100
fe3d6a54 __1cCosFabort6Fl_v_ (1, fe4d0634, 1, ceb80, fe4d0634,
ceb803c4) + b8
fe31bcf8 __1cMreport_error6Flpkci11E_v_ (e4, fe464d50, ceb80c44,
fe464848, fe541250, fe4d0634) + 400
fe31b5b0 __1cMreport_fatal6Fpkci1E_v_ (d9, fe4d0634, fe464d50, ceb81,
fe4d0634, ceb81584) + 60
fe0f8850 __1cNExceptionMark2t5B6MrpnGThread__v_ (d957e210, ceb81658,
fe4d0634, f68000c0, fe4d0634, ceb815e4) + 5c
fe0f7284
__1cTconstantPoolOopDescSklass_at_if_loaded6FnSconstantPoolHandle_i_pnMklassOopDesc__
(de990fd0, de8a6558, ceb816ec, f700c4e8, fe4d0634, ceb81674) + 1a0
fe164830
__1cNmethodOopDescbEfast_exception_handler_bci_for6MnLKlassHandle_ilpnGThread__i_
(f7004f60, f7005980, ceb817c8, 144, bc6600, ceb816fc) + 190
fe16423c
__1cSInterpreterRuntimebFexception_handler_for_exception6FpnKJavaThread_pnHoopDesc__pC_
(bc6600, f68379c8, ceb819b8, fe4d0634, bc6600, 109a0) + 338
000ad9b8 ???????? (ceb8194c, 1, fe4df218, b7b20, 8, ceb81848)
fe53ade8 __1cMStubRoutinesG_code1_ (ceb819d8, ceb81c10, a, f7005a00, 4,
ceb818f0) + 3fc
fe0cd5b0
__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_
(ceb81c08, fe4d0634, ceb81b54, bc6600, adecc, ceb81c10) + 388
fe1f918c
__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThread__v_
(ceb81a24, ceb81d70, 7fd70, fe4d0634, ceb81b54, bc6600) + 1bc
fe1ff0f8
__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_
(ceb81c08, ceb81c04, ceb81c00, ceb81bf4, ceb81bec, bc6600) + 60
fe21d8b0 __1cMthread_entry6FpnKJavaThread_pnGThread__v_ (f6818388,
bc6600, fe4d0634, ceb81d10, 1e, e) + c8
fe218434 __1cKJavaThreadDrun6M_v_ (fe4d0634, bc6600, ceb02000, 0, 0, 0)
+ 27c
fe2162a8 _start (fe4d0634, bc6600, 296b98, 5, 1, fe401000) + 2c
ff36b728 _thread_start (bc6600, 0, 0, 0, 0, 0) + 40
Apart from one crash which had different stack trace. It may or may not
be related to the main problem:
ff369764 __sigprocmask (ff36bf60, 0, 0, ccc81d70, ff37e000, 0) + 8
ff35e110 _sigon (ccc81d70, ff385930, 6, ccc8008c, ccc81d70, 6) + d0
ff361150 _thrp_kill (0, 169, 6, ff37e000, 169, ff2c0450) + f8
ff24ba1c raise (6, 0, 0, ffffffff, ff2c03bc, 4) + 40
ff23593c abort (ff2bc004, ccc801e0, 0, fffffff8, 4, ccc80201) + 100
fe3c98e4 __1cNRootCollectorBf6FppnHoopDesc__v_ (1, fe4cc020, 1, ccc80,
fe4cc020, ccc801fc) + cc
fe319534
__1cPClassFileParserbSparse_constant_pool_interfacemethodref_entry6MnSconstantPoolHandle_i_v_
(e4, ccc80a7c, d3, fe4568b0, fe53cb50, fe4cc020) + 4c
fe318e04 __1cVclassfile_parse_error6FpkcpnGThread__v_ (d3, fe4cc020,
fe456d90, ccc81, fe4cc020, ccc813bc) + 60
fe0f7ca8 __1cOis_range_check6FpnENode_r12ri_i_ (d7f709a0, ccc81490,
fe4cc020, f68000c0, fe4cc020, ccc8141c) + 58
fe0f66dc __1cIPhaseCFGGbldcfg6MppnENode_rnJVectorSet__I_ (0, 0,
ccc81524, f693c170, fe4cc020, ccc814ac) + 240
fe163550
__1cNinstanceKlassPlink_class_impl6FnTinstanceKlassHandle_pnGThread__v_
(f6edc870, f6edd788, ccc81600, 21, f078b0, ccc81534) + 308
fe163010 __1cKMemBarNodeFmatch6MpknIProjNode_pknHMatcher__pnENode__
(f078b0, d8a4a960, ccc816d8, fe4cc020, f078b0, 109a0) + f4
000ad8e8 ???????? (ccc8178c, ccc81814, ccc81818, b7a50, 10, ccc81688)
000abfac ???????? (ccc8181c, f078b0, ccc819b8, b7d00, 10, ccc81720)
000abfd0 ???????? (ccc818c4, db6a2d28, 28, b7d00, 8, ccc817a8)
000abfd0 ???????? (ccc8194c, 1, fe4dab18, b7a50, 4, ccc81848)
fe5366e8 __1cMStubRoutinesG_code2_ (ccc819d8, ccc81c10, a, f7005910, 4,
ccc818f0) + b1c
fe0cc108 __1cMPhaseIterGVNVadd_users_to_worklist6MpnENode__v_
(ccc81c08, fe4cc020, ccc81b54, f078b0, addfc, ccc81c10) + 1ac
fe1f7350 __1cNRememberedSetRscavenge_contents6FpnIOldSpace__v_
(f7005c00, ccc81b40, ccc81b44, fe4cc020, ccc81c08, ccc81b54) + 124
fe1fd3b4 __1cSThreadLocalStorageKset_thread6FpnGThread__v_ (ccc81c08,
ccc81c04, ccc81c00, ccc81bf4, ccc81bec, f078b0) + 70
fe21bcd8
__1cHCompileTGenerate_Stub_Graph6MpknITypeFunc_pCpkcpnIciMethod_pnPciInstanceKlass_illll_v_
(f6818388, f078b0, fe4cc020, ccc81d10, 1e, e) + 1ff8
fe2167d8 __1cOMacroAssemblerEfmov6MnNFloatRegisterFWidth_11_v_
(ccc02000, fe4d7e64, fe4cc020, 7fd70, f078b0, 7fd70) + 154
fe21450c __1cIAbsDNodeLbottom_type6kM_pknEType__ (fe4cc020, d2825d10,
0, 5, 1, fe401000) + 10
ff36b728 _thread_start (f078b0, 0, 0, 0, 0, 0) + 40
The HotSpot error output in the stdout log looks like this
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 455843455054494F4E530E43505000D9 01
#
# Problematic Thread: prio=5 tid=0x14d9a48 nid=0x46f runnable
#
The first stack trace looks very similar to that shown in Sunbug
4854693. The issue has been worked through Dave Korbel with the
following progress:
1. We were asked to whether any of the symptoms from bugs 5056374 and
5040492 (and any of the related bugs) are present. The answer was, and
still is, no.
2. We were asked whether we agreed that the bug was the same as 5056374.
We were told that a workaround for this bug was to not use
Thread.stop(). As the customer is not using Thread.stop() in their code,
I am not convinced that these bugs are the same.
Since there seems no connection with 5056374 and 5040492, this bug has
been raised.
###@###.### 10/19/04 01:11 GMT