Community
Participate
Working Groups
The method ElementTree.immutable() seems to have possible concurrency problems (reader and writers). Further investigation is needed. NOTES: RTP (4/17/01 6:23:32 PM) DeltaDataTree.lookup This is the method related to the problem of having readers while calling ElementTree.immutable(). If this method is ok, we are safe.
This is a tricky situation. The vulnerability is in the following two lines (from DeltaDataTree#reroot(DeltaDataTree)): parent.setRootNode(backwardDelta.getRootNode()); parent.setParent(sourceTree); Between the method calls to setRootNode and setParent, the tree pointed to by "parent" will be inconsistent. Any form of read on the tree during that critical period will probably fail. Note that writes are not possible anyway because the tree must be immutable at this point already. The failure mode could be bad, as it could hit an assertion (for example in DeltaDataTree#getChildNodes) that results in a runtime exception. At least such a failure would only affect the read that happened during the critical region, and wouldn't leave the tree in a bad state. This is expensive to fix. Making it safe would require an extra sync block for every tree read, where currently no sync block is needed. This would slow down all tree reads. So the final question is: do we make it safe, thus impacting performance for all tree operations, or risk the rare failure and leave it as-is? Since there has never been a report of failure here, and it would only cause read-only operations to fail (which by definition can't do much damage), I would suggest leaving it.
PRODUCT VERSION: Eclipse SDK 0.044
Not critical, defer.
Reopening for investigation.
Closing. Although there is a theoretical vulnerability, we have never seen a problem in practice in the two years since this bug was opened.
