ClasspathUpdaterTest randomly fails #820
Labels
test
Test case failure
Comments
laeubi
changed the title
|
failed both test_CreateFromScratch and test_CreateFromScatch_WithTestPluginName with same error about missing library.jar |
|
I assume it is a JDT job running in the background, what I did somewhere else is before starting an action, install a job listener that puts all scheduled jobs in a list, then after the action I join on all these jobs (with a timeout) that way it is ensured that all jobs that are scheduled during an operation (e.g. update the classpath in the background) complete. Another option would be to retry the assertions for some time until they eventually succeed. |
|
test_CreateFromScatch_WithTestPluginName, |
|
can be locally reproduced on win:
|
|
logged stacktrace of root cause: |
|
org.eclipse.jdt.internal.core.JavaModelManager.PerProjectInfo.rootPathToRawEntries is set in running in parallel with |
jukzi
added a commit
to jukzi/eclipse.pde
that referenced
this issue
Feb 5, 2025
Avoid setClasspath in NotifyJob concurrent to test execution eclipse-pde#820
|
There are also 3 more jobs calling setClasspath concurrently: and and |
|
See #820 (comment) where I described how you can capture jobs scheduled during execution of some method (e.g. record on test start and join before testing assertions). |
|
Thanks, but i don't get how that should help against jobs that are already scheduled independent of the runnable. Also it seems to not to protect against deadlock due to jobs that reschedule themselves like Workbench Auto-Save Job, Periodic workspace save, Compacting resource model. |
If they are not scheduled as part of the runnable then they are not caused by the calling code and then one would not need to wait for them.
It just collects what jobs are scheduled (not sure why it should be a deadlock here), you can do whatever you want with this, e.g wait for a few seconds to join these, ignore them whatever you like. |
|
i actually tried your idea with Which deadlocks for example on BlockedJobsDialog$1 and does not join the independent scheduled jobs mentioned in #820 (comment) - which can interfere with the test! |
|
I don't see why you want to wake up the job... and I would join with a timeout for this purpose. And of course it only works if not something is happen in the background randomly, as this is out of your control it can happen anytime so no way to "wait" for this and one maybe better use a |
to avoid joining a sleeping job
Then i could equally just sleep a fixed time without complicated mechanism, because i know it will timeout |
If the job is sleeping then it should not run (yet) anyways and join will return immediately. The |
nah, its scheduled with a delay and would run during the test, which is the task to avoid |
|
I tried a lot waits now. Either the test is wrong or the functionality is broken: |
jukzi
added a commit
to jukzi/eclipse.pde
that referenced
this issue
Feb 5, 2025
fixes random failing ClasspathUpdaterTest eclipse-pde#820
jukzi
added a commit
to jukzi/eclipse.pde
that referenced
this issue
Feb 6, 2025
fixes random failing ClasspathUpdaterTest When IJavaProject.setRawClasspath() is explicitly called with ClasspathEntries distinct from PDE (like in the Test), and then later PDEs UpdateClasspathJob is executed it can't compute the "oldEntry" and fails with "... is not on its projects build path". The Message is correct - it was manually removed from the projects build path. That state should just be ignored so that PDE continues to set the IClasspathEntries computed by PDE. eclipse-pde#820
jukzi
added a commit
to jukzi/eclipse.pde
that referenced
this issue
Feb 6, 2025
fixes random failing ClasspathUpdaterTest When IJavaProject.setRawClasspath() is explicitly called with ClasspathEntries distinct from PDE (like in the Test), and then later PDEs UpdateClasspathJob is executed it can't compute the "oldEntry" and fails with "... is not on its projects build path". The Message is correct - it was manually removed from the projects build path. That state should just be ignored so that PDE continues to set the IClasspathEntries computed by PDE. eclipse-pde#820
jukzi
added a commit
that referenced
this issue
Feb 6, 2025
fixes random failing ClasspathUpdaterTest When IJavaProject.setRawClasspath() is explicitly called with ClasspathEntries distinct from PDE (like in the Test), and then later PDEs UpdateClasspathJob is executed it can't compute the "oldEntry" and fails with "... is not on its projects build path". The Message is correct - it was manually removed from the projects build path. That state should just be ignored so that PDE continues to set the IClasspathEntries computed by PDE. #820
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See https://github.com/eclipse-pde/eclipse.pde/runs/18054276230
@iloveeclipse do you have any clue what might be the culprit here? We also see instabilities on Java 21 as reported here:
so this test seem to do something "special" or has a timing problem...
The text was updated successfully, but these errors were encountered: