Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 312179

Summary:

Impossible to safely acquire any scheduling rules in syncExec/asyncExec

Product:

[Eclipse Project] Platform

Reporter:

James Blackburn <jamesblackburn+eclipse>

Component:

Runtime

Assignee:

platform-runtime-inbox <platform-runtime-inbox>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

major

Priority:

CC:

sptaszkiewicz, sxenos, yevshif

Version:

3.6

Target Milestone:

---

Hardware:

OS:

All

Whiteboard:

stalebug

Attachments:

Description	Flags
test 1	none
Illegal push backtrace	none
asyncExec illegal push exception	none

Description James Blackburn

2010-05-09 08:03:52 EDT

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.

Comment 1 James Blackburn

2011-03-25 06:50:37 EDT

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...

Comment 2 Szymon Ptaszkiewicz

2013-03-22 14:51:41 EDT

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();

Comment 3 Stefan Xenos

2016-12-20 22:14:04 EST

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.

Comment 4 Eclipse Genie

2020-02-13 16:53:11 EST

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.