Bugzilla – Full Text Bug Listing
| Summary: | SWTExceptions occurring when handling notifications from worker thread transactions | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] GMF-Runtime | Reporter: | Neeraj Bhope <neerajbhope> | ||||||
| Component: | General | Assignee: | Steven R. Shaw <steveshaw> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | blocker | ||||||||
| Priority: | P3 | CC: | ahunter.eclipse, bnicolle, fplante, give.a.damus, mgoyal, schafe | ||||||
| Version: | 1.0 | ||||||||
| Target Milestone: | 1.0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 142803 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Neeraj Bhope
Is there a stack trace that could be added to give an indication where the deadlock is occurring? Steve; is not that defect similar to the threading issue you are working on Why is this defect BP3, Major? Submitter or Owner, please mark as BP1, Blocker (I cannot). I cannot drag-and-drop onto a diagram without hanging workbench on Linux. In my environment, it is 100% reproducible. Bumped up the severity. Only owner can change the priority. Requires fix from 142803 before this can be addressed... - A new api is available for clients when responding to notification that come from a worker thread but they need access to SWT or resources reserved for the main thread. @see EditPartUtil#synchronizeRunnableToMainThread. Should be only be used when the client is sure that in the stack of execution SWT resources will be accessed directly. Otherwise, this could incur a performance penalty when handling notifications. Also, it may spawn the runnable asynchronously to the main thread which may break assumptions on ordering when the events are handled. - Instrumented this api in the installBendpointEditPolicy method. Created attachment 44444 [details]
Alternate patch for this problem that is more general...
Some clients have indicated they are still encountering deadlock scenarios with progress meter forked operations. Progress meter notifications are currently still handled on the worker thread which opens up clients to encountering SWTExceptions. Since a recent transaction api fix was made which avoids deadlocks (146341), we can now synchronize notifications to the main thread irregardless of the progress meter use-case. This is a more broad solution which avoids instrumenting specific parts of client code to synchronize to the main thread.
Waiting for client confirmation before reopening this defect...
Reopened to consider this new patch which is a more generic fix. Targetting RC5. + renamed bugzilla to more reflective of the generic problem Downgrading to major until it is known whether another usecase exists where the generic fix would be necessary. Moving to 1.0.1 unless there are objections... Confirmed with clients that original point fix is not sufficient (just exposes other problem areas) and that the generic fix is required to avoid SWTExceptions. Created attachment 44643 [details]
update patch
Found another problem in DeferredLayoutCommand which calls refresh to update the shapes positions. This causes can cause initialization of fonts. Have to wrap this in a synchExec as well. Patch has been updated accordingly...
Committed - For progress meter operations that fork a thread for execution, SWTExceptions were sometimes occurring when doing static initialization in client code. Now DiagramEventBrokerThreadSafe will always synchronize notifications to the main thread using the privilegedRunnable irregardless of whether updates are disabled. [target cleanup] 1.0 RC5 was the original target milestone for this bug [GMF Restructure] Bug 319140 : product GMF and component Runtime Diagram was the original product and component for this bug |