The bug description below is a bit misleading, so I'm restating the problem:
Bigapp Vtest server crashes due to bad oop. Last time we used binaries from
merlin_beta 04/16 and b60.
The bug can be reproduced on NT and linux-x86.
If you need assistance to get the latest traces or reproduce the bug, please contact me.

###@###.###


JDK version
=============
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b58)
Java HotSpot(TM) Server VM (build 1.4.0-beta-b58, mixed mode)

Platform
=============
Windows_NT JTG-WIN5 5 00 586

Error message
=============
Vtest server hang after 12 mins
Hanging process will leave there until we run next build.

Notes
=============
please check http://jtgb4u4c.eng/bigapps for test results tables

Testing results are backupped in
jtg-win1 that can be accessed by telnet (root/admin as id/passwd) or http://jtg-win1
  
How to reproduce bug:
telnet to the hosts shown in web for linux test machine with root/admin as id/passwd
goto z:/1.3NTscripts to execute script and d:/tmp to get the running results
for example:
telnet to jtg-win2 with root/admin as id/passwd
execute sh z:/1.3NTscripts/runxxxxx.ksh stab -server (give the "stab" as 1st para)
cd to d/tmp/runxxx.xxx-server to get the results
dxoshin.chen@eng 2001-04-10
============================================================================
JDK version
=============
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b59)
Java HotSpot(TM) Server VM (build 1.4.0-beta-b59, compiled mode)

Error message
=============
Vtest server fail immediately on jtg-win4
[Thu Apr 12 14:28:54 PDT 2001] Error reading from JTG-WIN4. (java.net.SocketException: Connection reset
by peer: JVM_recv in socket input stream read)

Vmark server fail immediately on jtg-win5
[Mon Mar 27 15:25:07 PST 2000] Error reading from JTG-WIN5. (java.net.SocketException: Connection reset
by peer: JVM_recv in socket input stream read)

dxoshin.chen@eng 2001-04-13

This bug also appears on VMark VTest on solaris x86 with -server Xcomp on bl60.
The stack trace is the same:

  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [15] oopDesc::mark(0x6983fe), at 0xded112de
  [16] ScanClosure::do_oop(0xdb330b0c, 0xcfb90940), at 0xded11072
  [17] OopMapSet::all_do(0xdb3309a0, 0xdb56ebc8, 0xdb3309ac, 0xdb330b0c, 0xdeead
3f0, 0xdefa3e08, 0xdefa3e08), at 0xded63631
  [18] OopMapSet::oops_do(0xdb3309a0, 0xdb56ebc8, 0xdb3309ac, 0xdb330b0c), at 0x
ded6380b
  [19] frame::oops_code_blob_do(0xdb3309a0, 0xdb330b0c, 0xdb3309ac), at 0xded637


coleen.phillimore@east 2001-04-18