Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FileInfoReader deadlock #568

Open
jukzi opened this issue Nov 18, 2024 · 1 comment
Open

FileInfoReader deadlock #568

jukzi opened this issue Nov 18, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@jukzi
Copy link
Contributor

jukzi commented Nov 18, 2024 

          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
@jukzi jukzi mentioned this issue Nov 18, 2024
Closed
@jukzi jukzi added the bug Something isn't working label Nov 18, 2024
@laeubi
Copy link
Member

laeubi commented Nov 18, 2024

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 pushed a commit to jukzi/p2 that referenced this issue Nov 18, 2024
@EcljpseB0T
MT hardening FileInfoReader eclipse-equinox#568
4586073 
The value of the barrier (true/false) was never read. It was only
checked for !=null. The value had been read in waitOnSelf() without any
multithreading semantics like synchronize/volatile.
Instead now we use a thread safe AtomicBoolean. The synchronization
blocks are still used for wait()/notifyAll()

eclipse-equinox#568
@jukzi jukzi mentioned this issue Nov 18, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@laeubi @jukzi