Community
Participate
Working Groups
Build 20020423 Marker#setAttributes may throw a NPE due to a missing null check on the line: MarkerInfo markerInfo = (MarkerInfo)resourceInfo.getMarkers().get(id); since #getMarkers() can answer null. ----- I came across a scenario where it did occur inside the JavaModel test suites. If you're interested in reproducing it, let me know.
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) { } }
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).
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?
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...
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.
Could it be due to some timestamp granularity ?
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)
Created attachment 720 [details] stack trace showing problem
Moving back to JDT. The NullPointerException has been fixed, but the test case still has problems.
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
