-
Notifications
You must be signed in to change notification settings - Fork 190
Assume minimal CPU configuration for the BusyIndicator test on Linux #3050
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.
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
Conversation
The test never fail locally with 32 cores, fails every second time on smaller VM configs. Let assume at least 4 cores on Linux. See eclipse-platform#3044
| @Test | ||
| @Timeout(value = 30) | ||
| public void testShowWhile() { | ||
| if (SwtTestUtil.isLinux) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sound completely off, why should the number of CPU core matter?!? Java can have 100 of parallel threads on a single CPU...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a better idea why the test hangs?
Let try that please. I'm tired to see the test failing every second day.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I do not have a theory here, but as I'm not aware it fails since its creation in Jun 23, 2024 it might be a bug/regression in GTK part of Linux.
Test is not really complex and the assumption it is in any way related to the number of CPUs does not hold true. Also why should it only fail on Linux then?
As you already noticed it even succeed on Hardware with less course, so any arbitrary number here will simply disable the test and hiding a possible bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #3051
|
OK, eclipse.org jenkins runs on smaller config with probably 2 cores, but github job has at least 4 cores (or assumption doesn't work) and is still hanging around on that test, which is strange, because it should be stopped by JUnit Timeout annotation, which seem not to work too on Jenkins (but works on SDK build, which means there is also test setup issue). @laeubi : do you prefer:
My goal is to have a clean build state without hangs or failures, so people can only see test failures related to the actual code changes. I don't have time for 3) and also feel myself not responsible to do that, as I didn't added this test. |
Just for the record the test was explicitly requested by reviewers so I feel at least to share the responsibility for this with others. Anyways, I can try to make the timeout and debugging for it a bit better if it helps...
Github has 4 CPUs, at least it seem to me to hang in GTK4 in the Github actions only so maybe @jonahgraham @akurtakov have a clue what might be a reason here as well. |
|
OK, looks like you have some ideas where the problem is coming from, so closing this PR. |
The test never fail locally with 32 cores, fails every second time on smaller VM configs. Let assume at least 4 cores on Linux.
See #3044