Original Synopsis was:
  JDI StepRequest with STEP_IN failure / jdb step failure

See testcase regressionTestsInWaiting/StepOutOfExcluded.sh

FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Windows NT Version 4.0

ADDITIONAL OPERATING SYSTEMS :




A DESCRIPTION OF THE PROBLEM :
In some cases a JDI StepRequest with depth STEP_IN does
not stop where it should. The problem can be seen in
the jdb using "step", and also in other debuggers. This
seems to happen when the line at which the step should
stop is called from an excluded class method, and a call
to an excluded class method occurs on that line (or
maybe something more general than that).

The problem does not happen if size STEP_MIN is used. The
problem does not happen if no step excludes are set.

This also happens with the JDI under JDK 1.3.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile StepInBug.java in debug mode and run jdb
StepInBug
2. enter command: stop at StepInBug:6
3. enter command: run
4. enter command: step

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expect the debugger to stop at line 12, but instead it
completes the toString() call and stops at line 7.

Note that if the first line of toString() is changed
to return "a"; the problem does not occur.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class StepInBug {
   
      public static void main(String[] args) {
         StepInBug sib = new StepInBug();
         // Set breakpoint on next line (6), then step in.
         System.out.println(sib);
      }
   
      public String b = "b";
      public String toString() {
         // Works fine if we take off the "+ b".
         return "a" + b;
      }
   }

---------- END SOURCE ----------
(Review ID: 160174)
======================================================================