So can ThreadReference.ownedMonitorsAndFrames().  In addition, ThreadReference.frames() can throw an NPE.

These problems are caused by the fix for 6700889.   They only occur if a resume is done on a thread in a small window of time while one of these commands is in  customer  in a different thread.
Posted Date : 2008-09-23 19:44:48.0

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

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.
Posted Date : 2008-09-23 19:48:36.0