EVALUATION

http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/dd7969318d7a
                                     

SUGGESTED FIX

Use a local reference for the cache in the affected methods. If a resume occurs and a new initialized cache object is created, it doesn't cause problems for simultaneously executing methods since they will continue working with the old cache object.

See attached webrev.
                                     

WORK AROUND

This bug can only occur if a debugger has multiple threads and calls any of the following methods in one thread while simultaneously resuming the same debuggee thread in a different debugger thread.  Debuggers shouldn't do this because it is a race condition and the result returned by these methods will vary depending upon just where in the processing of these methods the resume takes effect.  EG, the frameCount() method could return 6 in a case where the debuggee has already been resumed and there are no frames.

After this bug is fixed, the invalid return values shown below will no longer be
returned and the related exceptions will not occur.
Until this bug is fixed, JDI clients can use the following workarounds:
- ownedMonitors() :  Treat null as an empty list
- ownedMontitorsAndFrames:  Catch NullPointerExceptions and treat as 
  a return value of an empty list
- frameCount:   Treat -1 as 0
- stackFrames:  Catch NPE and treat as a return value of an empty list
                                     

EVALUATION

Data for the methods described in the description are cached in the JDI front-end while a thread is suspended, to avoid unnecessary JDWP calls that would fetch the identical data.  The cache is reset when the debuggee thread is resumed.   If this reset occurs at the right time during the execution of one of the specified methods, then the reset cache value is returned or used.