Project: Eclipse_Platform_UI
Bug 238397 [Commands] Concurrent modification possible in DefaultOperationHistory
Reported: 2008-06-25 08:05:46 | Status: verified fixed

Build ID: 3.3.3.r33x_r20080129 Steps To Reproduce: This is kind of hard to reproduce, nevertheless the systematic gap can be seen directly within the coding. Please have a look into the coding of the method flushUndo(...) in org.eclipse.core.commands.operations.DefaultOperationHistory. The undoList.remove is triggered without any synchronization (in contrast to the other coding locations the list is modified). This may lead to ConcurrentModificationExceptions in case of very rapidly fired Undo/redo events (in fact that's what happended within one of our automated tests). Furthermore, the method filter(...) called right before the for-loop first gets an iterator for the list, then aquires the lock an then loops over the iterator. In rare cases this may lead to IndexOutOfBoundsExceptions when another thread modified the list in between getting the iterator and looping over it (actually also this happened in the mentioned test case). From my point of view the lock should already by aquired in the flushUndo before calling the filter(...) method. More information: I'm sorry for not being able to offer a reproducable code snippet, since our case we spotted this needs a quite complicated setup, a lot of testdata and used quite a lot of parallel threading.

Files changed in fix:
bundles/org.eclipse.core.commands/src/org/eclipse/core/commands/operations/DefaultOperationHistory.java