On machine jtgbp62d.sfbay, with Merlin build 79,  customer  server hang after 30 minutes with -server flag.
Error message in atgserver.log
"Unexpected Signal: 11, PC: de9671c8"

Segv in "compute_monomorphic_entry". 
Stack trace: 
  ---- called from signal handler with signal 11 (SIGSEGV) ------ 
  [9] CompiledIC::compute_monomorphic_entry(0x827b074), at 0xde9671c8 
  [10] OptoRuntime::inner_resolve_helper(0x827a928), at 0xde95202c 
  [11] OptoRuntime::resolve_helper(0x827a928), at 0xde951e46 
  [12] OptoRuntime::resolve_opt_virtual_call_C(0x827a928), at 0xde96b7f7

log files are under /net/jtgb4u4c.sfbay/export/sail9/bigapps_log/solaris/merlin_b79/jtgbp62d/ customer *
there is a gcore (core.317) under  
/net/jtgb4u4c.sfbay/export/sail9/bigapps_log/solaris/merlin_b79/jtgbp62d/ customer *


  xxxxx@xxxxx   2001-09-17

The problem is a race between the deoptimization of
some method X and the dynamic linkage which occurs
at the first call to X.  The linker asks for the
compiled code twice (in rapid succession) and loses
if the compiled code is thrown away between the
two queries.

This bug often shows up during start-up or other phase
changes in the application, since it requires the linker
to be performing a one-time initialization a call site.

Therefore, perturbing the application so that it
performs less deoptimization should lower the probability
of this bug hitting.  One way to attempt this is to have the
compiler compile more selectively and slowly, such as
with a setting like -XX:CompileThreshold=20000 .

  xxxxx@xxxxx   2002-02-19

Diagnosis:  Race condition between call to methodOop::has_compiled_code
and methodOop::code.  The methodOop::_code field slowly oscillates between
null and non-null, and the hapless caller of has_compiled_code picked
up a newly-set null pointer and indirected through it.

Solution:  Visit all places where has_compiled_code() and code()!=NULL
predicates are used, and change them to fetch the code exactly once
instead of twice.

  xxxxx@xxxxx   2001-09-28

The bug is fixed in JDK1.4.0-beta3-b84(merlin-beta3)
  xxxxx@xxxxx   2001-12-10

The bug is also fixed in 1.3.1_03, not yet released, but soon.

  xxxxx@xxxxx   2002-01-03

So what version is this bug being fixed in????

Yes, where is this fixed? Error still occurs in 1.3.1_01.

Will this be fixed in 1.3.1_02? If so when is this 
available? Or will the fix only be available in merlin 
(beta4?)

Obviously it is not fixed in 1.3.1_02.  Is there any work 
around before 1.3.1_03 is available??  Thanks.

Is this fixed or not, If yes which version.