[jdt-debug-dev] Re: [eclipse-dev] [eclipse-build]Build I20030506 (Timest

[Jared Burns <jared-eclipse@xxxxxxxxx>]

Anyone getting anywhere on these problems yet?

I'm looking at the first exception - getting null from getVM() inside 
JDIDebugTarget#jdiClassesByName(). From the stack trace, it looks like when 
we set the inclusion filters on the breakpoint in this test, it's trying to 
recreate the breakpoint request for a previous launch that didn't clean up 
correctly. It seems that you can only get null from getVM() if you call it 
after cleanup() has been called. The breakpoint code tries to protect against 
this by checking if the target isAvailable() before it creates a new request.

The first possibility I see is a thread synchronization problem. 
JavaBreakpoint#recreate(JDIDebugTarget) first checks if the target is 
available. You can get the answer "true" and then proceed to try to recreate 
the request. Another thread can then terminate or disconnect the target, 
calling cleanup and setting the VM to null. When the first thread starts 
running again and tries to recreate the request, getVM() will return null.

The second possibility can happen when a JDIDebugTarget has called cleanup() 
and but hasn't set the terminated or disconnected flags true. It looks like 
this can only happen if we go through the shutdown() method badly, but that 
doesn't make any sense because that's only called during plugin shutdown.

- Jared

On Tuesday 06 May 2003 09:31 am, Darin Wright wrote:
> The debug team is investigating these failures.