The current Kestrel version of jdb loses track of which frame in a stack backtrace is being examined after executing a "print" or "dump" statement. This behavior appears to be VM- and platform-independent: it has been reproduced on Win32/HotSpot, Win32/Classic, and Sparc/Classic. Sparc/HotSpot appears to have a bug (4296019) preventing this test from being run.

Sample code:
public class JDBStackFrameBug {

    private static void staticMethod() {
int localInt = 3;
System.out.println("staticMethod()");
    }

    public static void main(String[] args) {
String localVar = "Hello";

try {
staticMethod();
}
catch (Exception e) {
e.printStackTrace();
}
    }
}

To reproduce:
% javac -g JDBStackFrameBug.java
% jdb -tclassic JDBStackFrameBug
Initializing jdb...
> stop in JDBStackFrameBug.staticMethod
Deferring breakpoint JDBStackFrameBug.staticMethod.
It will be set after the class is loaded.
> run
run JDBStackFrameBug
>
VM Started: Set deferred breakpoint JDBStackFrameBug.staticMethod

Breakpoint hit: thread="main", JDBStackFrameBug.staticMethod(), line=4, bci=0
  4 int localInt = 3;

main[1] up
main[2] print localVar
 localVar = "Hello"
main[1] print localVar
Name unknown: localVar

Note that after the first "print" the current stack frame has been reset to 1.