Customer has seen multiple crashes on more than one system using java 5.0

stack trace:
  ---- called from signal handler with signal 10 (SIGBUS) ------
  [8] LinkResolver::runtime_resolve_virtual_method(0xb977f088,
0xc223c150, 0x40,
 0x10, 0xb977e8ac, 0x1), at 0xfe973de0
  [9] LinkResolver::resolve_invokevirtual(0x1f0258, 0x0, 0x1f0274, 0x0,
0x17b2c8
8, 0x1f0264), at 0xfe97fef4
  [10] LinkResolver::resolve_invoke(0xb977f088, 0xb977ea68, 0xb977ea64,
0x21, 0x
b6, 0x17b2c88), at 0xfe960b98
  [11] SharedRuntime::find_callee_info_helper(0xb977f080, 0x17b2c88,
0x1f0604, 0
xb977f084, 0xb977f088, 0x17b2c88), at 0xfe9e8e78
  [12] SharedRuntime::resolve_sub_helper(0x0, 0x17b2c88, 0x1, 0x0,
0x17b2c88, 0x
775dac), at 0xfe9eda40
  [13] SharedRuntime::resolve_helper(0xb977f3fc, 0x17b2c88, 0x1, 0x0,
0x17b2c88,
 0x7c00), at 0xfe9ed754
  [14] OptoRuntime::resolve_virtual_call_C(0x17b2c88, 0x9559b419,
0xc295b5e8, 0x
db577370, 0x9, 0x6), at 0xfeac24bc
  [15] 0xf8834568(0xf2fa45f0, 0xc295b5e8, 0xdb577370, 0x0, 0xee5a0000,
0xee5a01f
8), at 0xf8834567
  [16] 0xf8c68800(0xc88a25d0, 0xf2fa45f0, 0xc223c150, 0xc2069310, 0x4e,
0x249d24
7e), at 0xf8c687ff
(dbx) frame 8
0xfe973de0: runtime_resolve_virtual_method+0x0284: ld [%l2 +
%i2], %i
2
(dbx) x runtime_resolve_virtual_method+0x0284
dbx: warning: unknown language, 'c' assumed
0xfe973de0: runtime_resolve_virtual_method+0x0284: 0xf404801a
(dbx) regs
current thread: t@null
current frame: [8]
g0-g3 0x00000000 0x001f0278 0x0000004a 0xc2238028
g4-g7 0x001f026c 0xffffffff 0x00000000 0xf85e1c00
o0-o3 0x88000021 0xb977e7dc 0x001f0274 0x00000001
o4-o7 0x00000040 0x0057e494 0xb977e780 0x0041004e
l0-l3 0x017b2c88 0xb977e8b4 0x00410156 0xfeef2000
l4-l7 0x00000000 0xb977e8b8 0x001f0604 0x001f0274
i0-i3 0xb977f088 0xc223c150 0x00000040 0x00000010
i4-i7 0xb977e8ac 0x00000001 0xb977e810 0xfe97fef4
y 0x00000000
ccr 0x00000000
pc 0xfe973de0:runtime_resolve_virtual_method+0x284 ld
[%l2 +
%i2], %i2
npc 0xfe973de4:runtime_resolve_virtual_method+0x288 cmp
%i2, 0
(dbx) dis runtime_resolve_virtual_method+0x0284
0xfe973de0: runtime_resolve_virtual_method+0x0284: ld [%l2 +
%i2], %i
2
0xfe973de4: runtime_resolve_virtual_method+0x0288: cmp %i2, 0
0xfe973de8: runtime_resolve_virtual_method+0x028c: bne,pn
%icc,runtime_re
solve_virtual_method+0x29c ! 0xfe973df8
0xfe973dec: runtime_resolve_virtual_method+0x0290: clr %i1
0xfe973df0: runtime_resolve_virtual_method+0x0294: ba
runtime_resolve
_virtual_method+0x2d8 ! 0xfe973e34
0xfe973df4: runtime_resolve_virtual_method+0x0298: cmp %i1, 0
0xfe973df8: runtime_resolve_virtual_method+0x029c: ld [%l0 +
140], %o
0
0xfe973dfc: runtime_resolve_virtual_method+0x02a0: ld [%o0 +
8], %i1
0xfe973e00: runtime_resolve_virtual_method+0x02a4: ld [%o0 +
12], %l4
0xfe973e04: runtime_resolve_virtual_method+0x02a8: add %i1, 4, %l6
(dbx)

SA came up blank with this thread.
one core simply showed nothing and another
had an error occuring during stackwalk.

core files are in /net/cores.central/cores/64438826/feb_01_test_crash
there is a read_core_1 that can be edited to open the core files.
.dbxrc is in that directory as well.
There is also another core in the directory
/net/cores.central/cores/64438826/core
there are other cores in /net/cores.central/cores/64438826/
under the core, and feb_03_crash
libs are contained within those subdirectories as well.




###@###.### 2005-2-04 19:01:21 GMT