random failing ServiceSupplierTestCase.testOptionalReferences #488

jukzi · 2023-06-09T09:34:25Z

on win

java.lang.AssertionError: expected:<1> but was:<2>
	at org.eclipse.e4.core.internal.tests.di.extensions.ServiceSupplierTestCase.testOptionalReferences(ServiceSupplierTestCase.java:267)

The text was updated successfully, but these errors were encountered:

HeikoKlare · 2023-06-22T09:19:31Z

Example for fail: https://github.com/eclipse-platform/eclipse.platform/actions/runs/5342777773/jobs/9685299025

…ipse-platform#488 The test case ServiceSupplierTestCase.testOptionalReferences randomly fails because it waits for asynchronous service registration using fixed-time sleep operations, which fail on slow machines. This change replaces the sleep operations with functionality that waits for changes of the service states. A timeout ensures that in case of a failure the wait operation is aborted.

The test case ServiceSupplierTestCase.testOptionalReferences randomly fails because it waits for asynchronous service registration using fixed-time sleep operations, which fail on slow machines. This change replaces the sleep operations with functionality that waits for changes of the service states. A timeout ensures that in case of a failure the wait operation is aborted.

HeikoKlare · 2023-07-28T09:46:36Z

Test failed again with a different error message in recent build
https://github.com/eclipse-platform/eclipse.platform/pull/595/checks?check_run_id=15421937193

java.lang.AssertionError
	at org.junit.Assert.fail(Assert.java:87)
	at org.junit.Assert.assertTrue(Assert.java:42)
	at org.junit.Assert.assertNotNull(Assert.java:713)
	at org.junit.Assert.assertNotNull(Assert.java:723)
	at org.eclipse.e4.core.internal.tests.di.extensions.ServiceSupplierTestCase.testOptionalReferences(ServiceSupplierTestCase.java:254)

Michael5601 · 2023-08-08T12:55:41Z

Failed again in this run in PR: #605

…ipse-platform#488 The ServiceSupplierTestCase.testOptionalReferences test case randomly fails. The test aims to wait for services to be enabled or disabled, but it only waits until a single value is changed although it asserts that multiple values are changed afterwards. This is a race condition, as the order in which the values are changed or in which the changes are visible is non-deterministic, also due to missing memory barriers. This change addresses this issue via two means: 1. it makes the fields of the asserted values volatile to ensure that changed values eventually become visible to the UI thread 2. it waits for all values to be changed before asserting their values to allow different orders of value changes

The ServiceSupplierTestCase.testOptionalReferences test case randomly fails. The test aims to wait for services to be enabled or disabled, but it only waits until a single value is changed although it asserts that multiple values are changed afterwards. This is a race condition, as the order in which the values are changed or in which the changes are visible is non-deterministic, also due to missing memory barriers. This change addresses this issue via two means: 1. it makes the fields of the asserted values volatile to ensure that changed values eventually become visible to the UI thread 2. it waits for all values to be changed before asserting their values to allow different orders of value changes

fedejeanne · 2023-11-29T09:34:12Z

Failed again in this build of #776

org.eclipse.e4.core.internal.tests.di.extensions.ServiceSupplierTestCase.testOptionalReferences -- Time elapsed: 0.070 s <<< FAILURE!
java.lang.AssertionError: expected same:<class org.eclipse.e4.core.internal.tests.di.extensions.DisabledServiceA> was not:<class org.eclipse.e4.core.internal.tests.di.extensions.DisabledServiceB>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotSame(Assert.java:829)
	at org.junit.Assert.assertSame(Assert.java:772)
	at org.junit.Assert.assertSame(Assert.java:783)
	at org.eclipse.e4.core.internal.tests.di.extensions.ServiceSupplierTestCase.testOptionalReferences(ServiceSupplierTestCase.java:270)

HeikoKlare · 2023-11-29T09:36:56Z

It is a different kind of failure after #829. I'll have a look.

jukzi · 2023-11-29T09:38:16Z

i can not reproduce it locally

HeikoKlare · 2023-11-29T09:39:13Z

It's a race condition and thus random failing.

HeikoKlare · 2023-11-29T09:51:21Z

Potential reason: the tests have been duplicated (for javax and jakarta, see #791) and I only applied #829 to one them.

jukzi · 2023-11-29T09:54:18Z

please change the classname of the new test to avoid confusion

HeikoKlare · 2023-11-29T09:57:52Z

In general, we would have to change the names/packages of all the duplicated code to ensure that we can identify in which of the implementation a problem arises. But we may again run into the problem that only one of the implementations is touched by maintenance. So from a maintenance perspective, this duplication is quite problematic.

jukzi · 2023-11-29T10:01:26Z

in stacktraces the package name is visible, while in some junit results it's not obvious

HeikoKlare · 2023-11-29T10:07:01Z

I see. One thing that can currently help is to look at the log and see which project was processed (which may also not be easy due to parallel build).

Concerning this specific issue the log shows that the error happens in the javax copy of the tests, which is the one that has not been corrected in #829. I will provide a PR to fix that.

…ipse-platform#488 Fixes two issues: 1. The ServiceSupplierTestCase asserts several values that are assigned by an asynchronous task. To this end, it waits for the conditions to be fulfilled by the asynchronous task. However, the conditions are incomplete, leading to a race condition. 2. The ServiceSupplierTestCase has been duplicated for javax and jakarta and a fix for a random failure has only been applied to a single implementation in eclipse-platform#829 This change corrects the conditions the test waits for and aligns both copies of the test class with each other. Fixes eclipse-platform#488

Fixes two issues: 1. The ServiceSupplierTestCase asserts several values that are assigned by an asynchronous task. To this end, it waits for the conditions to be fulfilled by the asynchronous task. However, the conditions are incomplete, leading to a race condition. 2. The ServiceSupplierTestCase has been duplicated for javax and jakarta and a fix for a random failure has only been applied to a single implementation in #829 This change corrects the conditions the test waits for and aligns both copies of the test class with each other. Fixes #488

…ipse-platform#488 The ServiceSupplierTestCase.testOptionalReferences test case randomly fails. The test aims to wait for services to be enabled or disabled, but it only waits until a single value is changed although it asserts that multiple values are changed afterwards. This is a race condition, as the order in which the values are changed or in which the changes are visible is non-deterministic, also due to missing memory barriers. This change addresses this issue via two means: 1. it makes the fields of the asserted values volatile to ensure that changed values eventually become visible to the UI thread 2. it waits for all values to be changed before asserting their values to allow different orders of value changes

…ipse-platform#488 Fixes two issues: 1. The ServiceSupplierTestCase asserts several values that are assigned by an asynchronous task. To this end, it waits for the conditions to be fulfilled by the asynchronous task. However, the conditions are incomplete, leading to a race condition. 2. The ServiceSupplierTestCase has been duplicated for javax and jakarta and a fix for a random failure has only been applied to a single implementation in eclipse-platform#829 This change corrects the conditions the test waits for and aligns both copies of the test class with each other. Fixes eclipse-platform#488

jukzi mentioned this issue Jun 9, 2023

use try-with-resource #481

Merged

HeikoKlare mentioned this issue Jun 22, 2023

Re-acquire locks via iterative instead of recursive execution #447 #450

Merged

HeikoKlare mentioned this issue Jun 22, 2023

Fix random failing ServiceSupplierTestCase.testOptionalReferences #488 #513

Merged

HeikoKlare closed this as completed in #513 Jun 27, 2023

HeikoKlare reopened this Jul 28, 2023

HeikoKlare mentioned this issue Jul 31, 2023

Reactivate tests #525 #603

Merged

Michael5601 mentioned this issue Aug 8, 2023

Reactivate tests in org.eclipse.core.tests.resources #525 #605

Closed

HeikoKlare mentioned this issue Sep 12, 2023

Make data setup in ParallelBuildChainTest explicit per test case #659 #660

Merged

jukzi added the test junit test related things label Nov 28, 2023

jukzi added the help wanted Extra attention is needed label Nov 29, 2023

HeikoKlare mentioned this issue Nov 29, 2023

Fix random failing ServiceSupplierTestCase.testOptionalReferences #488 #895

Merged

HeikoKlare closed this as completed in #895 Nov 29, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

random failing ServiceSupplierTestCase.testOptionalReferences #488

random failing ServiceSupplierTestCase.testOptionalReferences #488

jukzi commented Jun 9, 2023

HeikoKlare commented Jun 22, 2023

HeikoKlare commented Jul 28, 2023

Michael5601 commented Aug 8, 2023

fedejeanne commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023

jukzi commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023

jukzi commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023

jukzi commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023

random failing ServiceSupplierTestCase.testOptionalReferences #488

random failing ServiceSupplierTestCase.testOptionalReferences #488

Comments

jukzi commented Jun 9, 2023

HeikoKlare commented Jun 22, 2023

HeikoKlare commented Jul 28, 2023

Michael5601 commented Aug 8, 2023

fedejeanne commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023

jukzi commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023

jukzi commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023

jukzi commented Nov 29, 2023

HeikoKlare commented Nov 29, 2023