###@###.### 2002-08-01

While testing a fix for the following bug:

    4721871 3/4 PopAsynchronousTest hits an assert intermittently

I ran into an unexpected java command failure. The test run was for 16
hours with the Hopper-B18 JDK with a Mantis libhprof, libjdwp and
Client VM on Solaris SPARC:

    java_g cmd finished 1963 iterations and all PASSed
    java cmd finished 13448 iterations and 5 FAILed

All 6 java cmd hangs were due to the following unexpected exception:

com.sun.jdi.InternalException: Unexpected JDWP Error: 113
        at com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:47)
        at com.sun.tools.jdi.StackFrameImpl.pop(StackFrameImpl.java:326)
        at com.sun.tools.jdi.ThreadReferenceImpl.popFrames(ThreadReferenceImpl.java:450)
        at PopAsynchronousTest$HarassThread.run(PopAsynchronousTest.java:114)
TEST FAILURE: exception com.sun.jdi.InternalException: Unexpected JDWP Error: 113

The JVM/DI PopFrame() interface has only one JVMDI_ERROR_INTERNAL error return:

  // Check to see if a PopFrame was already in progress
  if (java_thread->popframe_condition() != JavaThread::popframe_inactive) {
    // Probably possible for JVMDI clients to trigger this, but the
    // JPDA backend shouldn't allow this to happen
    JVMDI_RETURN(JVMDI_ERROR_INTERNAL);
  }

Did an overnight stress run (16+ hours) with Hopper-B18 bits. The
java cmd finished 10828 iterations and 1 FAILed with same unexpected
exception as above.


###@###.### 2002-09-13

On a U80 2X450 MHZ running Solaris 8, the frequency of the failure increases
as the work load on the machine decreases. The bug has yet to be seen with
the java_g cmd so it is best to run the java cmd doit_loop by itself overnight.
That yields 5-10 failures.


###@###.### 2002-09-23

This bug now tracks just the JPDA backend cause for the failure. See

4751814 4/4 PopFrame intermittently returns JVMDI_ERROR_INTERNAL

For the JVM/DI cause for the failure.