Community
Participate
Working Groups
Created attachment 167624 [details] test 1 As per bug 294894 comment 17, I think this is a sufficiently interesting bug that it warrants filing with test. The effect of this issue is that it's always unsafe to modify an IResource in a syncExec. Modifying a resource: 1. Locks the resource scheduling rule 2. acquires the workspace lock This issue occurs when: 1) workspace lock is locked, for example due to concurrent notification, someone checking into the workspace, etc. 2) resource modification is attempted on UI thread. - Resource rule acquired - ws lock attempted => pending work run 3) If pending work attempts a conflicting scheduling rule (such as modifying a non-contained resource) this pending work fails. The issue is that the individual syncExecs are obviously unaware of any scheduling rules already held by the UI thread, and unaware of each other. This problem seems peculiar to syncExec (asyncExecs are not run via lockListener -- though they are run when acquiring scheduling rules (see bug 262032)). Perhaps it should be documented that certain operations, such as modifying resources, are unsafe in a syncExec.
Created attachment 191901 [details] Illegal push backtrace I experienced this bug for real in my runtime eclipse. As the event loop is ticked during modal dialogs any held scheduling rules can collide...
Created attachment 228937 [details] asyncExec illegal push exception The same problem happens also in case of asyncExec. The following UIJob was used to reproduce illegal push during file save: new UIJob("async") { public IStatus runInUIThread(IProgressMonitor monitor) { try { Job.getJobManager().beginRule(ResourcesPlugin.getWorkspace().getRoot(), null); } finally { Job.getJobManager().endRule(ResourcesPlugin.getWorkspace().getRoot()); } return null; } }.schedule();
The problem with syncExec isn't interesting -- syncExec itself is highly deadlock-prone and can't really be safely called in any situation. We should deprecate it and remove all usage from the platform. If there's a problem with asyncExec, that's much more interesting.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
