Skip to content

Conversation

@iloveeclipse
Copy link
Member

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

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) {
Copy link
Contributor

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...

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #3051

@iloveeclipse
Copy link
Member Author

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:

  1. disable this test on Linux (as it seem to be Linux specific issue).
  2. assume 8 cores (so it will run on most "real" configurations but not on test machines.
  3. analyze and debug the root cause of the test hang and test failure.

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.
So 1) or 2) is my current proposal for which I can spend time.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 3, 2026

Test Results

  147 files   - 29    147 suites   - 29   20m 34s ⏱️ - 8m 15s
4 684 tests ± 0  4 662 ✅ ± 0  22 💤 ±0  0 ❌ ±0 
  415 runs   - 70    410 ✅  - 69   5 💤  - 1  0 ❌ ±0 

Results for commit 444bb48. ± Comparison against base commit c891c43.

@laeubi
Copy link
Contributor

laeubi commented Feb 4, 2026

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...

but github job has at least 4 cores (or assumption doesn't work) and is still hanging around on that test

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.

@iloveeclipse
Copy link
Member Author

OK, looks like you have some ideas where the problem is coming from, so closing this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants