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