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

["Darin Wright" <Darin_Wright@xxxxxxxxxx>]

I filed a bug for this problem:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=37264

The problem is concurrency - a target may disconnect/terminate at anytime. For example, one target may be shutting down while a breakpoint is added/removed/changed. We did not properly check for <null> being returned from #getVM() in about 42 locations. I have fixed this (as well as calls to #getEventRequestManager()). 

I believe the first failure caused the 2nd failure to occurr. The 2nd failure looks like it left an active target, which caused the next 3 failures (i.e. incorrect number of breakpoint removed callbacks).

The fixes are released and I have requested a re-build.

Darin

Jared Burns <jared-eclipse@xxxxxxxxx> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx 05/06/2003 11:35 AM Please respond to jdt-debug-dev

To:        jdt-debug-dev@xxxxxxxxxxx         cc:                 Subject:        [jdt-debug-dev] Re: [eclipse-dev] [eclipse-build]Build I20030506 (Timestamp:  200305060800):Automated JUnit Testing complete.  Test failures/errors occurred.

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.
_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev