[PATCH] dmstyle/tests: Relax style descriptor test with nothing loaded
Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> --- This test has been failing on the Windows 7 testbot since February 26, likely because of a Windows update. dlls/dmstyle/tests/dmstyle.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/dlls/dmstyle/tests/dmstyle.c b/dlls/dmstyle/tests/dmstyle.c index ed12315a19..a773607f8b 100644 --- a/dlls/dmstyle/tests/dmstyle.c +++ b/dlls/dmstyle/tests/dmstyle.c @@ -458,9 +458,8 @@ static void test_parsedescriptor(void) /* Nothing loaded */ hr = IDirectMusicObject_GetDescriptor(dmo, &desc); ok(hr == S_OK, "GetDescriptor failed: %08x, expected S_OK\n", hr); - ok(desc.dwValidData == DMUS_OBJ_CLASS /* XP */ || - broken(desc.dwValidData == (DMUS_OBJ_OBJECT | DMUS_OBJ_CLASS)), /* Vista and above */ - "Got valid data %#x, expected DMUS_OBJ_OBJECT\n", desc.dwValidData); + ok(desc.dwValidData & DMUS_OBJ_CLASS, + "Got valid data %#x, expected DMUS_OBJ_CLASS\n", desc.dwValidData); ok(IsEqualGUID(&desc.guidClass, &CLSID_DirectMusicStyle), "Got class guid %s, expected CLSID_DirectMusicStyle\n", wine_dbgstr_guid(&desc.guidClass)); -- 2.16.2
On 03/15/2018 06:11 AM, Alex Henrie wrote:
Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> --- This test has been failing on the Windows 7 testbot since February 26, likely because of a Windows update. Heh, that's when I added that test: git log 9ae8b8c00f2c dlls/dmstyle/
I noticed the issue two days later and tried to reproduce it with TestBot job 36301 (already deleted on the testbot). I couldn't! Here's are reruns with just a whitespace change: https://testbot.winehq.org/JobDetails.pl?Key=36793 https://testbot.winehq.org/JobDetails.pl?Key=36794 https://testbot.winehq.org/JobDetails.pl?Key=36795 Consistently not reproducible when run manually. Consistently reproducible when run as part of the daily run but *only* on newtb-w7pro64-32: The returned data is not random, always an extra DMUS_OBJ_VERSION that shouldn't be there. I've compared the dll version and it is on all the exact same dmstyle 6.1.7600.16385 That's why I asked back then Francois: [23:37:06] <puk> fgouget_: Tag: newtb-w7pro64-32 [23:37:14] <puk> fgouget_: which box is that? [23:37:37] <puk> w7pro64 (32 bit) ? [23:38:04] <puk> because I don't see test failures when running the tests manually on the WTB [23:38:17] <puk> newtb-w7pro64-32 is the only one to show it [23:59:35] <fgouget_> puk: it's a test VM, I think you can ignore it as I will take it down soon [23:59:52] <fgouget_> set as in for testing the TestBot, not for testing Wine [23:59:56] <fgouget_> s/set/test/ So I'm ignoring that issue as it will go away. bye michael
dlls/dmstyle/tests/dmstyle.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/dlls/dmstyle/tests/dmstyle.c b/dlls/dmstyle/tests/dmstyle.c index ed12315a19..a773607f8b 100644 --- a/dlls/dmstyle/tests/dmstyle.c +++ b/dlls/dmstyle/tests/dmstyle.c @@ -458,9 +458,8 @@ static void test_parsedescriptor(void) /* Nothing loaded */ hr = IDirectMusicObject_GetDescriptor(dmo, &desc); ok(hr == S_OK, "GetDescriptor failed: %08x, expected S_OK\n", hr); - ok(desc.dwValidData == DMUS_OBJ_CLASS /* XP */ || - broken(desc.dwValidData == (DMUS_OBJ_OBJECT | DMUS_OBJ_CLASS)), /* Vista and above */ - "Got valid data %#x, expected DMUS_OBJ_OBJECT\n", desc.dwValidData); + ok(desc.dwValidData & DMUS_OBJ_CLASS, + "Got valid data %#x, expected DMUS_OBJ_CLASS\n", desc.dwValidData); ok(IsEqualGUID(&desc.guidClass, &CLSID_DirectMusicStyle), "Got class guid %s, expected CLSID_DirectMusicStyle\n", wine_dbgstr_guid(&desc.guidClass));
Missatge de Michael Stefaniuc <mstefani(a)winehq.org> del dia dj., 15 de març 2018 a les 13:40:
On 03/15/2018 06:11 AM, Alex Henrie wrote:
Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> --- This test has been failing on the Windows 7 testbot since February 26, likely because of a Windows update. Heh, that's when I added that test: git log 9ae8b8c00f2c dlls/dmstyle/
I noticed the issue two days later and tried to reproduce it with TestBot job 36301 (already deleted on the testbot). I couldn't! Here's are reruns with just a whitespace change: https://testbot.winehq.org/JobDetails.pl?Key=36793 https://testbot.winehq.org/JobDetails.pl?Key=36794 https://testbot.winehq.org/JobDetails.pl?Key=36795
Consistently not reproducible when run manually. Consistently reproducible when run as part of the daily run but *only* on newtb-w7pro64-32: The returned data is not random, always an extra DMUS_OBJ_VERSION that shouldn't be there.
I've compared the dll version and it is on all the exact same dmstyle 6.1.7600.16385
That's why I asked back then Francois: [23:37:06] <puk> fgouget_: Tag: newtb-w7pro64-32 [23:37:14] <puk> fgouget_: which box is that? [23:37:37] <puk> w7pro64 (32 bit) ? [23:38:04] <puk> because I don't see test failures when running the tests manually on the WTB [23:38:17] <puk> newtb-w7pro64-32 is the only one to show it [23:59:35] <fgouget_> puk: it's a test VM, I think you can ignore it as I will take it down soon [23:59:52] <fgouget_> set as in for testing the TestBot, not for testing Wine [23:59:56] <fgouget_> s/set/test/
So I'm ignoring that issue as it will go away.
Understood, thanks for the explanation. If setting DMUS_OBJ_VERSION is not necessarily wrong, it might be a good idea to take the patch anyway. At the very least, the patch improves the failure message to match what was actually tested. But I defer to the sole guru of DirectMusic ;-) -Alex
On 03/16/2018 05:40 AM, Alex Henrie wrote:
Missatge de Michael Stefaniuc <mstefani(a)winehq.org> del dia dj., 15 de març 2018 a les 13:40:
On 03/15/2018 06:11 AM, Alex Henrie wrote:
Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> --- This test has been failing on the Windows 7 testbot since February 26, likely because of a Windows update. Heh, that's when I added that test: git log 9ae8b8c00f2c dlls/dmstyle/
So I'm ignoring that issue as it will go away.
Understood, thanks for the explanation. If setting DMUS_OBJ_VERSION is not It is not setting that, it fresh objects are created with that outside the control of the app.
necessarily wrong, it might be a good idea to take the patch anyway. At the It is more for documenting inconsistencies between the different IDirectMusicObject implementations. So I'd rather add another broken or so.
very least, the patch improves the failure message to match what was actually tested. But I defer to the sole guru of DirectMusic ;-) My gut feeling tells me something else is wrong, some unitialized memory or maybe reuse of a previous object, who knows. The non-reproducible part during manual test runs makes it very annoying to troubleshoot. There's some time until Jeremy comes after me at WineConf so I'd rather keep it at least until I get to cleanup dmstyle.
bye michael
participants (2)
-
Alex Henrie -
Michael Stefaniuc