Run of the following two JCK vm tests within one subsuite with HotSpot 
(jdk1.3.0P) in singleJVM mode causes HotSpot crash.
vm/concepts/exceptions/exceptions031/exceptions03101/exceptions03101.html
vm/concepts/exceptions/exceptions031/exceptions03102/exceptions03102.html

Although each of the tests catches StackOverflowError exception and
handles it, HotSpot crashes with the following error message:

An irrecoverable stack overflow has occurred.
#
# HotSpot Virtual Machine Error, Unexpected Signal 11
#
# Error ID: 4F533F534F4C415249530E43505007B5 01
#

Run of these tests within one subsuite with Classic VM (jdk1.3.0P) in 
singleJVM mode doesn't cause a crash.
Also, run of JCK vm subsuite with HotSpot, singleJVM mode with one of 
the tests excluded doesn't cause a crash, neither does run of each test
with HotSpot, singleJVM mode separately.
Run of JCK vm subsuite with both tests included with HotSpot, singleJVM
mode on WinNT doesn't cause a crash.

Seems like HotSpot on Solaris incorrectly behaves when two 
StackOverflowErrors occur in different threads but inside one JVM.

The tests exist in JCK122, they were never excluded.

======================================================================

  xxxxx@xxxxx  , 07 Dec 1999:

Decoded ErrorID reads: "os_solaris.cpp, 1973" 

To reproduce the failure, try 'doit.sh' in the directory:
    /net/sqesvr/vsn/GammaBase/Bugs/4296554
Posted Date : 2006-02-02 18:10:48.0

N/A

Brad or anyone else that maybe evaluatng this: Please, check the progress on 4282531. It is the same test and it also happens on win32. Please, close it as duplicate if you think that is the right thing to do. Robert is in the responsible engineer. But, he has been too busy with jvmpi and has not had time to look at this. thank you so much.
  xxxxx@xxxxx   1999-12-03

Moe - it's platform specific so John's fix won't address the wintel failure,
but probably a similar fix would.     (  xxxxx@xxxxx   1999-12-10)


  xxxxx@xxxxx   1999-12-08

Problem is that the stack yellow zone is disabled on the first occurrence
of a stack overflow for a thread, but never re-enabled after the
StackOverflowError is thrown.  The next stack overflow thus enters the
red zone, which the vm treats as fatal.  The attached simple java program
so2.java demonstrates this.

Need to determine at which point it is safe to re-enable the memory protection
on the yellow zone, and then do so.

  xxxxx@xxxxx   1999-12-10

A fix for this jck failure is to leave the stack yellow zone enabled after
a StackOverflowError.  Leaving it enabled allows the vm to correctly detect
multiple overflows on the same thread, but has the disadvantage of taking
away the "breathing room" on the stack for the java-level exception handler
to execute.  Thus, a handler for StackOverflowError which makes calls will
very likely cause a core dump; however, one which simply returns or exits
(the logical thing to do, in response to a StackOverflowError) will function
properly.

Creating a new (lower priority) bug for a usable yellow zone (bugid 4298656).