Test_org_eclipse_swt_custom_BusyIndicator fails on Linux

[iloveeclipse]

Most recent fail: https://download.eclipse.org/eclipse/downloads/drops4/I20260201-1800/testresults/html/org.eclipse.swt.tests_ep439I-unit-linux-x86_64-java25_linux.gtk.x86_64_25.html

testShowWhile() timed out after 30 seconds

java.util.concurrent.TimeoutException: testShowWhile() timed out after 30 seconds
at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)

Looking at the code, could it be, the common thread pool that is used by CompletableFuture.runAsync() code in the test simply has no free executor threads to run, or that they don't have a free core to be executed? Note, our test instances run on VM's with limited CPU resources.

[iloveeclipse]

@laeubi : could you please check ?

[laeubi]

The common poll ensures a given concurrency that is the number of cores. If some threads are blocked new ones are spawned so blocking for new tasks should never occur.
It might be that some other error arise so it actually never completes.

[iloveeclipse]

The common poll ensures a given concurrency that is the number of cores. If some threads are blocked new ones are spawned so blocking for new tasks should never occur.

I just remember we had a problem in the past with code blocked by a common pool.
So let merge that and see if this helps?

[laeubi]

I just remember we had a problem in the past with code blocked by a common pool.

Can you give a reference?

[iloveeclipse]

Can you give a reference?

Unfortunately no. I believe this was in platform, platform UI or jdt.

[iloveeclipse]

OK, found it.
See

• eclipse-platform/eclipse.platform@8271dce
• eclipse-jdt/eclipse.jdt.core@d16aa5d
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=576646#c30

[laeubi]

Reading through the bugs description it seem to be hindered by this

ForkJoinPool The pool attempts to maintain enough active (or available) threads by dynamically adding, suspending, or resuming internal worker threads, even if some tasks are stalled waiting to join others. However, no such adjustments are guaranteed in the face of blocked I/O or other unmanaged synchronization. The nested ForkJoinPool.ManagedBlocker interface enables extension of the kinds of synchronization accommodated.

So "parallel save" and "workspace rule" seem to exactly be the "bad" cases you should never do in a ForkJoinPool... It might be possible that waiting for a latch is equally bad (even though it was only chosen for test purpose here).

[iloveeclipse]

#3046 is merged, let see whether it would help or not.

[HeikoKlare]

The latest Jenkins run of the following PR got stuck at the BusyIndicator test again:

• [Win32] Check widget for disposal before zoom change notification #3047

This is the run which I aborted:

• https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-3047/1/

[ERROR] org.eclipse.swt.tests.junit.AllTests.testShowWhile -- Time elapsed: 4486 s <<< ERROR!

It was rebased on master after the fix attempt was merged:

• Sort out common pool as the possible root cause for test hangs #3046

So maybe that one did unfortunately not help.

[iloveeclipse]

Ideally we should start this test with something like TimeoutDumpTimer (see eclipse-platform/eclipse.platform.ui@cdcc797), unfortunately it is in the wrong repo, but that can be copy/pasted.

Just failing with non-saying JUnit failure stack doesn't bring us forward.