Bug 237314

Summary: NullPointerException when swtiching targets
Product: [Eclipse Project] PDE Reporter: Alex Fitzpatrick <agfitzp>
Component: UIAssignee: Curtis Windatt <curtis.windatt.public>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: caniszczyk, curtis.windatt.public, karasiuk
Version: 3.4   
Target Milestone: 3.4.1   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on:    
Bug Blocks: 237166    
Attachments:
Description Flags
patch with synchronized keyword none

Description Alex Fitzpatrick CLA 2008-06-16 13:34:06 EDT 
Build ID: 3.4RC4

Steps To Reproduce:
Repeatable with Sun and IBM 1.6 vms
IES target

1. Use workspace preferences to switch targets


More information:
An internal error occurred during: "Resetting Target Platform".

java.lang.NullPointerException
at org.eclipse.pde.internal.core.JavadocLocationManager.getEntry(JavadocLocationManager.java:52)
at org.eclipse.pde.internal.core.JavadocLocationManager.getJavadocLocation(JavadocLocationManager.java:39)
at org.eclipse.pde.internal.core.PDEClasspathContainer.getClasspathAttributes(PDEClasspathContainer.java:123)
at org.eclipse.pde.internal.core.PDEClasspathContainer.addExternalPlugin(PDEClasspathContainer.java:69)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addPlugin(RequiredPluginsClasspathContainer.java:255)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(RequiredPluginsClasspathContainer.java:229)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(RequiredPluginsClasspathContainer.java:213)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.computePluginEntries(RequiredPluginsClasspathContainer.java:129)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.getClasspathEntries(RequiredPluginsClasspathContainer.java:88)
at org.eclipse.jdt.internal.core.ClasspathEntry.validateClasspathEntry(ClasspathEntry.java:1567)
at org.eclipse.jdt.internal.core.ClasspathValidation.validate(ClasspathValidation.java:69)
at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:51)
at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:112)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:775)
at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:4703)
at org.eclipse.pde.internal.core.PluginModelManager.updateAffectedEntries(PluginModelManager.java:239)
at org.eclipse.pde.internal.core.PluginModelManager.modelsChanged(PluginModelManager.java:164)
at org.eclipse.pde.internal.core.PluginModelManager.resetState(PluginModelManager.java:853)
at org.eclipse.pde.internal.core.TargetPlatformResetJob.run(TargetPlatformResetJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Comment 1 Alex Fitzpatrick CLA 2008-06-16 14:36:26 EDT 
This only seems to happen the first time the target is set (or reset?).

Once the target has been set, and failed because of the error, it is possible to make the workspace "sane" by reloading and reapplying the target again.
Comment 2 Curtis Windatt CLA 2008-06-16 17:24:03 EDT 
Race condition between the reset job and getting javadoc locations.  Almost identical to bug 228297.  Can be easily solved by synchronizing the getEntry method instead of the initialize method, so that the location map can't be reset in the middle of the lookup.  Only concern is that concurrent lookups would be slowed down as they would have to wait for each other. To avoid this, a read/write lock could be used (though Java didn't provide an implementation until 1.5).
Comment 3 Alex Fitzpatrick CLA 2008-06-16 17:52:07 EDT 
That seems to do the trick.
Comment 4 Alex Fitzpatrick CLA 2008-06-16 18:00:27 EDT 
Created attachment 105097 [details]
patch with synchronized keyword

for completeness... patch implementing simple synchronization
Comment 5 Curtis Windatt CLA 2008-07-10 15:15:56 EDT 
*** Bug 240376 has been marked as a duplicate of this bug. ***
Comment 6 Curtis Windatt CLA 2008-07-10 15:17:16 EDT 
Consider fixing in M1.
Comment 7 Curtis Windatt CLA 2008-07-15 15:07:11 EDT 
Did some more testing/investigating and it's unlikely that entries will be requested from multiple threads at the same time (typically done sequentially in the same thread).  Even if there are multiple threads, the performance difference will be undetectable.  Rather than creating a custom implementation of a read/write lock, it's safer to go with the simple solution.

Fixed in HEAD by adding the synchronize.
Comment 8 Chris Aniszczyk CLA 2008-07-29 15:41:15 EDT 
fixed in 3.4.1 too