The test does not trace any window handle so there is no value to correlate the value in the failure message with. So showing this ever changing value is useless as is.
Signed-off-by: Francois Gouget fgouget@codeweavers.com --- dlls/dxgi/tests/dxgi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dlls/dxgi/tests/dxgi.c b/dlls/dxgi/tests/dxgi.c index e2b5df7b272..16482ae12ee 100644 --- a/dlls/dxgi/tests/dxgi.c +++ b/dlls/dxgi/tests/dxgi.c @@ -5060,8 +5060,8 @@ static BOOL check_message(const struct message *expected,
static LRESULT CALLBACK test_wndproc(HWND hwnd, unsigned int message, WPARAM wparam, LPARAM lparam) { - ok(!expect_no_messages, "Got unexpected message %#x, hwnd %p, wparam %#lx, lparam %#lx.\n", - message, hwnd, wparam, lparam); + ok(!expect_no_messages, "Got unexpected message %#x, wparam %#lx, lparam %#lx.\n", + message, wparam, lparam);
if (expect_messages) {
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=67193
Your paranoid android.
=== w2008s64 (64 bit report) ===
dxgi: dxgi.c:5063: Test failed: Got unexpected message 0x46, wparam 0, lparam 0x22fa20. dxgi.c:5063: Test failed: Got unexpected message 0x24, wparam 0, lparam 0x22f690. dxgi.c:5063: Test failed: Got unexpected message 0x1a, wparam 0x2f, lparam 0x22fa48.
On Sun, 15 Mar 2020, Marvin wrote: [...]
=== w2008s64 (64 bit report) ===
dxgi: dxgi.c:5063: Test failed: Got unexpected message 0x46, wparam 0, lparam 0x22fa20. dxgi.c:5063: Test failed: Got unexpected message 0x24, wparam 0, lparam 0x22f690. dxgi.c:5063: Test failed: Got unexpected message 0x1a, wparam 0x2f, lparam 0x22fa48.
The patch was designed to avoid false positives from messages such as WM_DWMNCRENDERINGCHANGED where lparam is 0:
https://testbot.winehq.org/JobDetails.pl?Key=67055#k108 dxgi.c:5063: Test failed: Got unexpected message 0x31f, hwnd 001C01E4, wparam 0x1, lparam 0.
But of course it won't help with unexpected WM_WINDOWPOSCHANGING, WM_GETMINMAXINFO and WM_WININICHANGE messages since lparam is a pointer for those (lparam is sometimes NULL for WM_WININICHANGE). Fortunately these are pretty rare, they happened only three times in the recorded history (vs. 153 instances of WM_DWMNCRENDERINGCHANGED):
Jan 27 - cw-rx460-32 https://test.winehq.org/data/cf6546fb3b914dc1d87b23d6920526b7487cfd6d/win8_c...
Jan 23 - w2008s64 https://test.winehq.org/data/c55e8822ae3bbb8b1d3ab9b363214e4ad2f478d9/2008_n...
Jan 01 - gtx560-32 Not available on test.winehq.org anymore.
On Mon, 16 Mar 2020 at 14:06, Francois Gouget fgouget@codeweavers.com wrote:
On Sun, 15 Mar 2020, Marvin wrote: [...]
=== w2008s64 (64 bit report) ===
dxgi: dxgi.c:5063: Test failed: Got unexpected message 0x46, wparam 0, lparam 0x22fa20. dxgi.c:5063: Test failed: Got unexpected message 0x24, wparam 0, lparam 0x22f690. dxgi.c:5063: Test failed: Got unexpected message 0x1a, wparam 0x2f, lparam 0x22fa48.
The patch was designed to avoid false positives from messages such as WM_DWMNCRENDERINGCHANGED where lparam is 0:
https://testbot.winehq.org/JobDetails.pl?Key=67055#k108 dxgi.c:5063: Test failed: Got unexpected message 0x31f, hwnd 001C01E4, wparam 0x1, lparam 0.
But of course it won't help with unexpected WM_WINDOWPOSCHANGING, WM_GETMINMAXINFO and WM_WININICHANGE messages since lparam is a pointer for those (lparam is sometimes NULL for WM_WININICHANGE). Fortunately these are pretty rare, they happened only three times in the recorded history (vs. 153 instances of WM_DWMNCRENDERINGCHANGED):
In general, this seems like just papering over the problems. But in this specific case, do we know why we get those spurious WM_DWMNCRENDERINGCHANGED messages? If they're legitimate, it shouldn't be too hard to specifically filter them out in test_wndproc().
Disclaimer: This is my opinion, all mine.
On Mon, 16 Mar 2020, Henri Verbeet wrote: [...]
dxgi: dxgi.c:5063: Test failed: Got unexpected message 0x46, wparam 0, lparam 0x22fa20. dxgi.c:5063: Test failed: Got unexpected message 0x24, wparam 0, lparam 0x22f690. dxgi.c:5063: Test failed: Got unexpected message 0x1a, wparam 0x2f, lparam 0x22fa48.
The patch was designed to avoid false positives from messages such as WM_DWMNCRENDERINGCHANGED where lparam is 0:
https://testbot.winehq.org/JobDetails.pl?Key=67055#k108 dxgi.c:5063: Test failed: Got unexpected message 0x31f, hwnd 001C01E4, wparam 0x1, lparam 0.
But of course it won't help with unexpected WM_WINDOWPOSCHANGING, WM_GETMINMAXINFO and WM_WININICHANGE messages since lparam is a pointer for those (lparam is sometimes NULL for WM_WININICHANGE). Fortunately these are pretty rare, they happened only three times in the recorded history (vs. 153 instances of WM_DWMNCRENDERINGCHANGED):
In general, this seems like just papering over the problems.
Sure in an ideal world Wine developers would treat WineTest failures as high priority and in a couple of weeks we'd have clean results. Then I could simplify the TestBot a great deal: a failure, any failure, could only be a NEW failure and the patch would never get committed in the first place.
But if that was meant to happen it would have happened YEARS AGO.
And it's not like this is of no consequence. If I understood Alexandre correctly at the last WineConf, false positives like these make the TestBot unusable for him.
That means he pays no attention to TestBot failures, thus letting in more broken tests that add new systematic and intermittent failures, keeping the TestBot in its broken state.
So I'm not going to bury my head in the sand and hope Wine developers suddenly start fixing more failures than they add.
My goal is to make the Testbot usable for Alexandre and that means getting rid of the false positives by any means.
**** * It's only once the incoming stream of broken tests is stopped * that we have any chance of cleaning the current mess. ****
So the choices are: 1. Fix the failures. 2. Tweak them so the TestBot can distinguish new from old. 3. Remove any test that causes false positives: remove the rot before it spreads.
JUST DO IT NOW!!!
But in this specific case, do we know why we get those spurious WM_DWMNCRENDERINGCHANGED messages? If they're legitimate, it shouldn't be too hard to specifically filter them out in test_wndproc().
I sure don't and already have enough on my plate with just the TestBot tasks.
Reminder: * https://www.winehq.org/pipermail/wine-devel/2020-February/160464.html -> TestBot's WINE TODO LIST: ***** OPEN TO ANY WINE DEVELOPER *****
* https://www.winehq.org/pipermail/wine-devel/2020-February/160559.html * https://www.winehq.org/pipermail/wine-devel/2020-February/160648.html * https://www.winehq.org/pipermail/wine-devel/2020-February/160707.html * https://www.winehq.org/pipermail/wine-devel/2020-March/161374.html
Thanks all for the feedback on these, btw.
-
Francois Gouget -
Francois Gouget -
Henri Verbeet -
Marvin