Community
Participate
Working Groups
Created attachment 277907 [details] Stacktrace While changing they layers on a Sirius diagram, Eclipse run into a deadlock, see the attached stack-trace. This deadlock is cased by bug 297770, the DefaultOperationHistory keeps locks while notifying changes in the undo history. In this case, Sirius is running updates on the UI-thread. Simultaneous, the layer changes is handled in a separate thread. This thread acquired the undo lock, and one of the listeners tries to run something on the UI thread. However, the UI thread is still busy. Then the UI-thread tries to acquire the undo lock, which is still hold by the other thread. The root cause of this bug might not be in Sirius, however, it seems that Sirius tries to update the undo history from two threads when changing layers which seems incorrect too.
Hello, Can you describe your odesign (or attach it here) and especially your layers? I have not been able to reproduce the deadlock and we also have JUnit and SWTBot tests that manipulates layers but does not end up in deadlock. Thank you, Steve
(In reply to Steve Monnier from comment #1) > Hello, > > Can you describe your odesign (or attach it here) and especially your > layers? I have not been able to reproduce the deadlock and we also have > JUnit and SWTBot tests that manipulates layers but does not end up in > deadlock. > > Thank you, > Steve Basically, by switching layers boxes are enabled/disabled within containers. I have 4 layers, that are all nested. When a layer is disabled, the nested elements are show in the 'container-container'. The model contains about 50 containers, 100 nested at the first level, 200 and third and and about 500 nested elements at 4th level. I have observed the behavior by disabling the 2nd or 3th layer. The deadlock does not occur all the time, so probably there is a race condition involved too. Note that I have ELK-GMF integration installed as well (and not ELK-Sirius integration).
Thanks for your detailed bug report. We have reproduced this issue and we reckon it is valid. I was able to reproduce the issue without ELK but also without a clear and reproductible scenario, it is random as it depends on when each thread wants to take the lock in the default operation history and or on the ui thread. In my case I have the command stack which has been flushed leading to a getCommand call on some GMG action which tries to access some SWT method. And on the other side I have the thread UI which is doing some async work and ties to get the Undo operation on the operation history. See attached stack trace. Nevertheless, it's not yet in the scope of a future release.
Created attachment 278057 [details] Second case of the same deadlock
