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

Bug 329333

Summary:

[Backport] Concurrent access to file while decorating

Product:

[Eclipse Project] Platform

Reporter:

Szymon Ptaszkiewicz <sptaszkiewicz>

Component:

Assignee:

Platform-UI-Inbox <Platform-UI-Inbox>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

bokowski, ob1.eclipse, pwebster, remy.suen, Szymon.Brandys, tomasz.zarna

Version:

3.7

Target Milestone:

3.6.2

Hardware:

OS:

Windows XP

Whiteboard:

Bug Depends on:

327192

Bug Blocks:

Attachments:

Description	Flags
Patch v.0.1	none

Description Szymon Ptaszkiewicz

2010-11-03 07:51:38 EDT

Bug cloned to track potential release into 3.6.2.

+++ This bug was initially created as a clone of Bug #327192 +++

The issue came out while working on bug 301223. The problem is that during project set import decorating thread and importing thread are both trying to use the same file. Decorating thread is calling file.getContentDescription() and importing thread is trying to delete this file to make space for incoming file from repository. The file is open because of decorator so delete operation is not successful which results in error during import. Delete operation uses scheduling rule but decorator is not. There should be added simple scheduling rule to decorate operation to prevent concurrent access and error during import.

Comment 1 Szymon Ptaszkiewicz

2010-11-03 12:03:05 EDT

Created attachment 182305 [details]
Patch v.0.1

Comment 2 Boris Bokowski

2010-11-15 11:51:51 EST

Does the thread that calls ContentTypeDecorator.decorate hold any other locks at the time it does beginRule?

Comment 3 Oleg Besedin

2010-11-15 16:48:02 EST

(In reply to comment #2)
> Does the thread that calls ContentTypeDecorator.decorate hold any other locks
> at the time it does beginRule?

It does not seem to hold any other locks, here is the typical state:

===

"Worker-8" prio=6 tid=0x1ffd4400 nid=0x13ac in Object.wait() [0x223ef000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x0b1c13e0> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.ThreadJob.waitForRun(ThreadJob.java:272)
	- locked <0x0b1c13e0> (a java.lang.Object)
	at org.eclipse.core.internal.jobs.ThreadJob.joinRun(ThreadJob.java:199)
	at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:92)
	at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:286)
	at org.eclipse.ui.internal.ide.ContentTypeDecorator.decorate(ContentTypeDecorator.java:46)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:269)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347)
	at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:371)
	at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:331)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

   Locked ownable synchronizers:
	- None


===

(The lock on the bottom is from Job.getJobManager().beginRule().)

Comment 4 Boris Bokowski

2010-11-15 17:04:55 EST

Thanks Oleg. +1 for 3.6.2.

Comment 5 Oleg Besedin

2010-11-16 11:32:05 EST

Patch applied to R3_6_maintenance. I also incremented version of the "org.eclipse.ui.ide" bundle from 3.6.1 to 3.6.2.

Comment 6 Oleg Besedin

2011-01-20 11:02:50 EST

Verified that the code is present in M20110119-0834.