[PATCH 0/1] MR4078: dmime/tests: Mark 3 PMsg tests as flaky
From: Michael Stefaniuc <mstefani(a)winehq.org> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55637 --- dlls/dmime/tests/dmime.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/dlls/dmime/tests/dmime.c b/dlls/dmime/tests/dmime.c index e390f86f1bf..6c5dec6a0e6 100644 --- a/dlls/dmime/tests/dmime.c +++ b/dlls/dmime/tests/dmime.c @@ -2853,9 +2853,9 @@ static void test_performance_pmsg(void) hr = IDirectMusicPerformance_SendPMsg(performance, msg); ok(hr == S_OK, "got %#lx\n", hr); hr = IDirectMusicPerformance_SendPMsg(performance, msg); - ok(hr == DMUS_E_ALREADY_SENT, "got %#lx\n", hr); + flaky_wine ok(hr == DMUS_E_ALREADY_SENT, "got %#lx\n", hr); hr = IDirectMusicPerformance_FreePMsg(performance, msg); - ok(hr == DMUS_E_CANNOT_FREE, "got %#lx\n", hr); + flaky_wine ok(hr == DMUS_E_CANNOT_FREE, "got %#lx\n", hr); hr = IDirectMusicPerformance_FreePMsg(performance, clone); ok(hr == S_OK, "got %#lx\n", hr); @@ -2991,7 +2991,7 @@ static void test_performance_pmsg(void) switch (delivery_flags[i]) { case DMUS_PMSGF_TOOL_IMMEDIATE: ok(duration <= 50, "got %lu\n", duration); break; - case DMUS_PMSGF_TOOL_QUEUE: ok(duration >= 50 && duration <= 125, "got %lu\n", duration); break; + case DMUS_PMSGF_TOOL_QUEUE: flaky ok(duration >= 50 && duration <= 125, "got %lu\n", duration); break; case DMUS_PMSGF_TOOL_ATTIME: ok(duration >= 125 && duration <= 500, "got %lu\n", duration); break; } } -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/4078
This merge request was approved by Michael Stefaniuc. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4078
I think the DMUS_E_ALREADY_SENT failures should not happen anymore after d0c3a0e03d557498195a70693003deae5b3e4588 (or rather much less frequently as it's always timing dependent). Regarding the timing test I'm not completely sure making it flaky is the best option. Maybe we should just get rid of the test entirely if there's too much variation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4078#note_48401
I think the DMUS_E_ALREADY_SENT failures should not happen anymore after d0c3a0e03d557498195a70693003deae5b3e4588 (or rather much less frequently as it's always timing dependent).
Right, forgot about that and just looked at the top of MR where I saw those failures.\ So those can be dropped then.
Regarding the timing test I'm not completely sure making it flaky is the best option. Maybe we should just get rid of the test entirely if there's too much variation.
You're not sure and I'm deferring the decision to you.\ So going with flaky is the simplest workaround for now to stop that noise. And then later on we can remove the whole test if it isn't that useful. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4078#note_48418
On Wed Oct 11 21:11:31 2023 +0000, Michael Stefaniuc wrote:
I think the DMUS_E_ALREADY_SENT failures should not happen anymore after d0c3a0e03d557498195a70693003deae5b3e4588 (or rather much less frequently as it's always timing dependent). Right, forgot about that and just looked at the top of MR where I saw those failures.\ So those can be dropped then. Regarding the timing test I'm not completely sure making it flaky is the best option. Maybe we should just get rid of the test entirely if there's too much variation. You're not sure and I'm deferring the decision to you.\ So going with flaky is the simplest workaround for now to stop that noise. And then later on we can remove the whole test if it isn't that useful. Do we know why we are getting these timing failures?
Getting 150 ms instead of 125 ms I can understand: just a scheduling delay because the system is busy. But how can we get 31 ms, less than the expected 50 ms minimum? What is the reasoning behind the 50 and 100 ms thresholds? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4078#note_48540
On Thu Oct 12 15:32:20 2023 +0000, Francois Gouget wrote:
Do we know why we are getting these timing failures? Getting 150 ms instead of 125 ms I can understand: just a scheduling delay because the system is busy. But how can we get 31 ms, less than the expected 50 ms minimum? What is the reasoning behind the 50 and 100 ms thresholds? No very clever reasoning, just some values which were supposedly different enough, as well as compatible with the performance default read-ahead which is apparently of ~70ms (difference between QUEUE and ATTIME delivery), and not too large to avoid slowing down the test.
Fwiw I only see spurious failures with unexpected high times (~265ms) for QUEUE delivery mode in the recent runs, maybe it's a genuine bug rather than timing failure. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4078#note_48541
This merge request was closed by Michael Stefaniuc. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4078
Closing, bug 55637 was fixed differently with 930776022d33b5d1745d59cd4a4671e1fd347b11. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4078#note_122665
participants (4)
-
Francois Gouget (＠fgouget) -
Michael Stefaniuc
-
Michael Stefaniuc (＠mstefani)
-
Rémi Bernon