Bug 14733

Comment 1 Philipe Mulet 2002-04-26 09:11:14 EDT

The sender of #setAttributes is creating the marker prior to modifying it. For 
some reason the marker info isn't available afterwards...

JavaProject#createClasspathProblemMarker(
		String message,
		int severity,
		boolean cycleDetected) {
		try {
			if (cycleDetected){
				String dummy = null;
			}
			IMarker marker = getProject().createMarker
(IJavaModelMarker.BUILDPATH_PROBLEM_MARKER);
			marker.setAttributes(
				new String[] { 
					IMarker.MESSAGE, 
					IMarker.SEVERITY, 
					IMarker.LOCATION, 
					IJavaModelMarker.CYCLE_DETECTED },
				new Object[] {
					message,
					new Integer(severity), 
					Util.bind("classpath.buildPath"),//$NON-
NLS-1$
					cycleDetected ? "true" : "false"});//
$NON-NLS-1$ //$NON-NLS-2$
		} catch (CoreException e) {
		}
	}

Comment 2 Philipe Mulet 2002-04-26 09:35:14 EDT

I traced the code so as to double check that the marker was correctly created 
and recorded into the project info markers slot.

However, when retrieving it for setting attributes, the slot has been cleared 
(suspecting the info was flushed in the meantime).

Comment 3 John Arthorne 2002-04-26 09:42:22 EDT

The NPE is easy to reproduce:

marker.delete();
marker.setAttribute(IMarker.MESSAGE, "Foo");

This will produce the NPE.  However in Philippe's case the marker has just been 
created so this shouldn't happen.  Philippe, would it be easy for us to load 
your tests to try reproducing this?

Comment 4 Philipe Mulet 2002-04-26 10:44:49 EDT

I will send you email for reproducing this defect.

Investigating more the defect, I am seeing a concurrency problem. In a 
background thread (indexer) I am also querying the resource info (asking 
#isLocal to resource), and thus it might recreate the info under the marker 
creation resulting in the NPE.

We might need to protect the background indexer with some Workspace runnables...

Comment 5 John Arthorne 2002-04-26 16:53:04 EDT

Released a fix for the NPE.  I haven't yet figured out what's happening in 
Philippe's case.  I can reproduce it every time when launched in "Run" mode, but 
can't reproduce at all in "Debug" mode.  This seems to be timing/concurrency 
related, but no other threads are manipulating the resource tree.

Comment 6 Philipe Mulet 2002-04-26 17:50:16 EDT

Could it be due to some timestamp granularity ?

Comment 7 John Arthorne 2002-04-29 13:09:48 EDT

I finally tracked it down.  The java model is deleting the marker in a resource 
change listener.  I am attaching a stack trace that shows what happens.  When 
you wrap the create/setAttributes in a workspace runnable, you don't experience 
the problem because the resource change listener doesn't get invoked until after 
the setAttributes call.

I was able to reproduce it today when running in debug mode.  I was thrown off 
last week because the JUnit UI shows a different stack trace when running in 
debug mode.  I can't figure out why this happens, but this is the stack trace I 
see when running the same test case in debug mode:

java.lang.NullPointerException
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

Comment 8 John Arthorne 2002-04-29 13:10:13 EDT

Created attachment 720 [details]
stack trace showing problem

Comment 9 John Arthorne 2002-04-29 13:11:24 EDT

Moving back to JDT.  The NullPointerException has been fixed, but the test case 
still has problems.

Comment 10 Philipe Mulet 2002-04-30 10:12:25 EDT

Reentering is indeed intriguing, but in this case a different marker is being 
deleted than the one added (first was a CP cycle marker, then next one was an 
unbound CP entry marker).

Cannot reproduce issue any longer (after removing the workspace runnable 
protection).
Closing