During heavy load testing of a BEA Weblogic 6.0sp2 app server running
on 1.3.1_02 we saw SEGV's in both -server and -client while attempting
to mark what appeared in the core file to be valid card table entries.
The problem was identified as follows:

"During heap expansion occurring not at a safepoint, the old generation
    was publishing the new "end" before the card table was expanded,
    allowing compiled code in other threads to allocate objects and
    thereby do card marks in an invalid memory region. New "end" is now
    published after expanding offset and card marking arrays."

1.3.1_02 (debug) regs:
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) regs
current thread: t@181
current frame: [1]
g0-g3 0x00000000 0xfa7ba000 0x003b3be8 0xffffe000
g4-g7 0xe8c01bf8 0x00000000 0x00000000 0xcb880000
o0-o3 0xe8c01bf8 0xf8c06fe8 0x00000043 0x000000c1
o4-o7 0xdc03fc50 0x00000000 0xcb87efe8 0xfb05a01c
l0-l3 0x0074600b 0x00000000 0x000000c1 0x00000104
l4-l7 0x0000016d 0x00000000 0x00000043 0x003b3be8
i0-i3 0xe8c01638 0xe8c01540 0x00000000 0x00000043
i4-i7 0x0000006c 0xe8bf2362 0xcb87f058 0xfb1b3818
y 0x00000000
ccr 0xfe401007
pc 0xfb059d64:0xfb059d64 stb %g0, [%g1 + %l0]
npc 0xfb059d68:0xfb059d68 mov %i0, %l0

1.3.1_02 (debug) stack trace:
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
current thread: t@181
=>[1] 0xfb059d64(0xe8c01bf8, 0xf8c06fe8, 0x43, 0xc1, 0xdc03fc50, 0x0), at 0xfb059d63
  [2] 0xfb05a01c(0xe8c01638, 0xe8c01540, 0x0, 0x43, 0x6c, 0xe8bf2362), at 0xfb05a01b
  [3] 0xfb1b3818(0xe8c01448, 0x43, 0x43, 0x43, 0xe12a3690, 0x0), at 0xfb1b3817
  [4] 0xfb1c8d78(0xdc03fbf8, 0xe8bf2270, 0xa, 0xe8bf2340, 0xb, 0x0), at 0xfb1c8d77
  [5] 0xfb1c86f0(0xdc03fbf8, 0xe8bf2438, 0xf96bddc0, 0xe2190, 0xe8bf2438, 0x0), at 0xfb1c86ef
  [6] 0xfb1c65ac(0xe1e200d0, 0xdc03dc70, 0xf96bdd40, 0xdc03ddc8, 0xf96bdd58, 0x4), at 0xfb1c65ab
...
  [20] JavaCalls::call_helper(0xcb87fd3c, 0xfef45940, 0xcb87fd34, 0x3b3be8, 0xcb87fb24, 0x5), at 0xfe6bf2bc
  [21] os::os_exception_wrapper(0xfe6beb70, 0xcb87fdf0, 0xcb87fc78, 0xcb87fd34, 0x3b3be8, 0x1), at 0xfe8acf54
  [22] JavaCalls::call(0xcb87fdf0, 0xcb87fc78, 0xcb87fd34, 0x3b3be8, 0xcb87fc84, 0xcb87fc80), at 0xfe6beb04
  [23] JavaCalls::call_virtual(0xcb87fc80, 0xcb87fc7c, 0xcb87fd28, 0xcb87fd24, 0xcb87fd34, 0x3b3be8), at 0xfe6bdbc0
  [24] JavaCalls::call_virtual(0xcb87fdf0, 0xcb87fde0, 0xcb87fddc, 0xcb87fdd8, 0xcb87fdd4, 0x3b3be8), at 0xfe6bdcbc
  [25] thread_entry(0x3b3be8, 0x3b3be8, 0x1, 0x0, 0x0, 0x0), at 0xfe737dfc
  [26] JavaThread::thread_main_inner(0x3b3be8, 0x3b47c0, 0x6, 0x0, 0x0, 0x0), at 0xfe9d41a8
  [27] JavaThread::run(0x3b3be8, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfe9d3fcc
  [28] _start(0x3b3be8, 0xcb880000, 0x0, 0x0, 0x0, 0x0), at 0xfe8a70c0