Bugzilla – Full Text Bug Listing
| Summary: | [prefs] Race condition in EclipsePreferences | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Min Idzelis <min123> | ||||
| Component: | Components | Assignee: | equinox.components-inbox <equinox.components-inbox> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | ||||||
| Version: | 3.4 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
The issue with the loadedNodes is covered by bug 158361 and has been fixed in both the 3.4.x builds and the 3.5 builds. *** This bug has been marked as a duplicate of bug 376206 *** |
Created attachment 109791 [details] JavaCore with stacks, etc Build ID: Eclipse 3.4Rac Steps To Reproduce: If two threads simultaneously access a Project preference for a preference node that hasn't been created yet, a race condition can result. If you look at EclipsePreferences's javadoc, it says " * Implementation notes: * * - For thread safety, we always synchronize on the node object when writing * the children or properties fields. Must ensure we don't synchronize when calling * client code such as listeners. " However, the lock is not held when the project node doesn't exist. The "create()" method in EclipsePreferences should be made threadsafe. Additionally, the state of the static field "loadedNodes" is shared and improperly synchronized. It should be wrapped with a synchronized set. Additionally, the method removeLoadedNodes() should synchronize on the set while it's iterating it.