FileInfoReader deadlock

[jukzi]

          Maybe an infinite loop waiting for org.eclipse.equinox.internal.p2.transport.ecf.FileInfoReader.barrier

waitOnSelf() does not synchronize the read on that while org.eclipse.equinox.internal.p2.transport.ecf.FileInfoReader.handleRemoteFileEvent(IRemoteFileSystemEvent) does synchronize for write

Originally posted by @jukzi in eclipse-pde/eclipse.pde#1481 (comment)

original reports:
eclipse-pde/eclipse.pde#1481
eclipse-pde/eclipse.pde#1160

[laeubi]

This code looks a bit suspicious on the other hand its there since 16 years now, so there are likely better ways today to solve this.

One part is also this one

p2/bundles/org.eclipse.equinox.p2.transport.ecf/src/org/eclipse/equinox/internal/p2/transport/ecf/FileInfoReader.java

Line 150 in 65348d6

barrier.notify();

it only notifies one thread, not all threads waiting... beside that it seem to be blocked in job.join() so has no chance to check the condition anyways...

[jukzi]

happens again - eclipse does not finish to start after update:

i sampled a bit:

[laeubi]

Thread State / Dump would be more interesting than CPU sampling. e.g. why does PDE hinders the IDE to start at all?

[jukzi]

Thread State / Dump would be more interesting than CPU sampling. e.g. why does PDE hinders the IDE to start at all?

see eclipse-pde/eclipse.pde#1481 (comment)

[laeubi]

From that stacktrace it seem to hang in a Java Editor that triggers init of classpath while showing a view (what triggers PDE to do something).

Still I'm wondering why all this happens before the UI is displayed....

[laeubi]

I have now analyzed this in more details, and the problem is IDEApplication.start(IApplicationContext) does suspend the JobManager, so no jobs are ever scheduled. Therefore the condition will never be meet and the code is running endlessly. It seems that this is particular happen with targlets (I can't reproduce this with plain PDE).

I tired to do some fixing for this in the FileInfoReader itself, but the problem is that ECF uses a job internally as well (that then will never run of course) so it does not help here much.

[laeubi]

The class has been overhauled now to not using any jobs or simple synchronization primitives so I think its safe to close this issue.

[vogella]

Thanks for working on this @laeubi

[jukzi]

i think it should be reopened since org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser.sendBrowseRequest() still uses Job.schedule whiich will not work with a suspended JobManager!

[laeubi]

see eclipse/ecf#154 so its nothing P2 can change here.