January 2022 - Wine-Devel - list.winehq.org

Re: [PATCH v4 1/4] wdscore: Implement CurrentIP.

by Gabriel Ivăncescu

On 29/01/2022 06:35, Mohamad Al-Jaf wrote: > Hi Giovanni, > > I see, thanks for the clarification. > > Yes, the patch solves the bug. Well, for the tests removing WINAPI seems > to change the pointer a bit, but it's still within the range so it > doesn't seem to affect it. > > I haven't tried it with __ASM_GLOBAL_FUNC, but it seems to work fine as > is. Along with the stubs in this patchset, wdscore functions > similarly to the native version, at least for the media creation tool. > > Still, I'm just wondering if using __ASM_STDCALL_FUNC isn't accurate? In > the CallCbsCore headers, CurrentIP is defined without WINAPI.[1] > > I don't know what to do now. If it's okay to use WINAPI, should I > resubmit the older version of this patch? > > [1] https://github.com/seven-mile/CallCbsCore/blob/master/StackManager.h Since it has no arguments and is not a "public" exported function it probably does not matter. But yes, using __ASM_STDCALL_FUNC without declaring it as WINAPI is a mismatch. You should be using either __ASM_GLOBAL_FUNC and no WINAPI, or __ASM_STDCALL_FUNC with WINAPI. I guess if the header doesn't use WINAPI, might as well make it without.

Jan. 29, 2022

Re: [PATCH 2/2] d3d8/tests: Ignore random testbot failures in test_cursor.

by Marvin

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=106431 Your paranoid android. === debian11 (32 bit report) === d3d8: device.c:10716: Test failed: Adapter 0: Expect window rect (0,0)-(640,480), got (4,14)-(644,494). === debian11 (32 bit Arabic:Morocco report) === d3d8: device.c:3183: Test failed: Expected message 0x3 for window 0, but didn't receive it, i=2. === debian11 (32 bit German report) === d3d8: device.c:3183: Test failed: Expected message 0x3 for window 0, but didn't receive it, i=2. device.c:10716: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (640,0)-(1280,480). === debian11 (32 bit French report) === d3d8: device.c:3183: Test failed: Expected message 0x1c for window 0x1, but didn't receive it, i=2. device.c:10746: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (0,0)-(1024,737). === debian11 (32 bit Hebrew:Israel report) === d3d8: device.c:3183: Test failed: Expected message 0x3 for window 0, but didn't receive it, i=2. device.c:10716: Test failed: Adapter 0: Expect window rect (0,0)-(640,480), got (4,14)-(644,494). === debian11 (32 bit Hindi:India report) === d3d8: device.c:3183: Test failed: Expected message 0x3 for window 0, but didn't receive it, i=2. device.c:10716: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (4,14)-(644,494). === debian11 (32 bit Japanese:Japan report) === d3d8: device.c:3183: Test failed: Expected message 0x3 for window 0, but didn't receive it, i=2. === debian11 (32 bit Chinese:China report) === d3d8: device.c:3183: Test failed: Expected message 0x1c for window 0x1, but didn't receive it, i=2. device.c:3345: Test failed: Expected message 0x1c for window 0x1, but didn't receive it device.c:10716: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (640,0)-(1280,480). device.c:10746: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (0,0)-(1024,737).

Jan. 29, 2022

Re: [PATCH v4 1/4] wdscore: Implement CurrentIP.

by Saulius Krasuckas

* On 2022-01-29 06:35, Mohamad Al-Jaf wrote: > Yes, the patch solves the bug. Well, for the tests removing WINAPI > seems to > change the pointer a bit, but it's still within the range so it doesn't > seem to affect it. ... > I don't know what to do now. If it's okay to use WINAPI, should I > resubmit > the older version of this patch? My 2c€ worth idea is to adhere with the K.I.S.S. principle: just keep the current version and let the function naturally be tested as much as possible. In case there occurs some bug eg. one containing stack overflow in the app (or something else) related to possibly incorrect use of CurrentIP(), this would be good stimuli for enhancing the implementation (and the tests). I continue below. * On 2022-01-21 01:03, you also asked Dmitry: >> the test doesn't verify that returned > value belongs to the dll address range > > Could you explain this? As Dmitry seemingly haven't responded to the list, I remind about this by sharing my understanding. Every process has its own virtual address space (VAS) [1]. The .exe file and each linked dll is mapped into a VAS and is given its own address (so-called ImageBase) and its size here (during the load time). Image base and size can be seen in the output of programs like ListDlls [2], CurrProcess [3]. The same pair or numbers can be calculated for every section of a dll (green boxes in the "Memory Map" pic [4]) or at least for executable sections only (red boxes in Figure 2 in [5]). It also can be done for every function exported by a dll [6]. Dmitry probably wanted to see whether the returned address belong: - to any of "Dynamic-base DLLs"; [1] - to the .text section of them; - to the the whole .exe file; - to the .text section of it; - to specifically the wdscore.dll; - to the .text section of it; - to the specific function of specific image; - to the stack of some (main) thread of the process; [1] This would require enumerating dlls mapped into the test process and extracting their image bases and sizes at least. I might perfectly be wrong with my guess. But at least it's a start (for the next step into advancing the test). S. [1] https://github.com/LordNoteworthy/windows-internals/blob/master/windows-int… [2] https://docs.microsoft.com/en-us/gaming/playfab/features/multiplayer/server… [3] https://www.nirsoft.net/utils/cprocess.html [4] https://blog.malwarebytes.com/threat-analysis/2013/06/my-memory-isnt-what-i… [5] https://www.cyberark.com/resources/threat-research-blog/masking-malicious-m… [6] https://www.codeproject.com/Articles/86215/Remote-Threads-Basics-Part-1#:~:…

Jan. 29, 2022

Re: [PATCH 1/2] d3d9/tests: Ignore random testbot failures in test_cursor.

by Marvin

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=106430 Your paranoid android. === w1064_2qxl (64 bit report) === d3d9: device.c:5268: Test failed: Didn't receive MOUSEMOVE 0 (50, 50). === debian11 (32 bit German report) === d3d9: device.c:4205: Test failed: Got unexpected screen size 720x480. device.c:4240: Test failed: Got unexpected screen size 720x480. device.c:4265: Test failed: Got unexpected width 720. device.c:4205: Test failed: Got unexpected screen size 720x480. device.c:4240: Test failed: Got unexpected screen size 720x480. device.c:4265: Test failed: Got unexpected width 720. === debian11 (64 bit WoW report) === d3d9: device.c:4205: Test failed: Got unexpected screen size 640x480. device.c:4240: Test failed: Got unexpected screen size 640x480. device.c:4265: Test failed: Got unexpected width 640. device.c:4386: Test failed: Expected message 0x3 for window 0x1, but didn't receive it, i=0. device.c:4205: Test failed: Got unexpected screen size 640x480. device.c:4240: Test failed: Got unexpected screen size 640x480. device.c:4265: Test failed: Got unexpected width 640. device.c:4266: Test failed: Got unexpected height 480. device.c:5424: Test failed: Expected resolution 1024x768, got 640x480. device.c:5454: Test failed: Expected resolution 1024x768, got 640x480.

Jan. 29, 2022

[PATCH 2/2] d3d8/tests: Ignore random testbot failures in test_cursor.

by Stefan Dösinger

Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com> --- dlls/d3d8/tests/device.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c index fc94dcaaad7..c288e1ef557 100644 --- a/dlls/d3d8/tests/device.c +++ b/dlls/d3d8/tests/device.c @@ -1074,11 +1074,19 @@ static void test_cursor(void) IDirect3DSurface8_Release(cursor); + /* On the testbot the cursor handle does not behave as expected in rare situations, + * leading to random test failures. Either the cursor handle changes before we expect + * it to, or it doesn't change afterwards (or already changed before we read the + * initial handle?). I was not able to reproduce this on my own machines. Moving the + * mouse outside the window results in similar behavior. However, I tested various + * obvious failure causes: Was the mouse moved? Was the window hidden or moved? Is + * the window in the background? Neither of those applies. Making the window topmost + * or using a fullscreen device doesn't improve the test's reliability either. */ memset(&info, 0, sizeof(info)); info.cbSize = sizeof(info); ok(GetCursorInfo(&info), "GetCursorInfo failed\n"); ok(info.flags & (CURSOR_SHOWING|CURSOR_SUPPRESSED), "The gdi cursor is hidden (%08x)\n", info.flags); - ok(info.hCursor == cur, "The cursor handle is %p\n", info.hCursor); /* unchanged */ + ok(info.hCursor == cur || broken(1), "The cursor handle is %p\n", info.hCursor); /* unchanged */ /* Still hidden */ ret = IDirect3DDevice8_ShowCursor(device, TRUE); @@ -1092,7 +1100,7 @@ static void test_cursor(void) info.cbSize = sizeof(info); ok(GetCursorInfo(&info), "GetCursorInfo failed\n"); ok(info.flags & (CURSOR_SHOWING|CURSOR_SUPPRESSED), "The gdi cursor is hidden (%08x)\n", info.flags); - ok(info.hCursor != cur, "The cursor handle is %p\n", info.hCursor); + ok(info.hCursor != cur || broken(1), "The cursor handle is %p\n", info.hCursor); /* Cursor dimensions must all be powers of two */ for (test_idx = 0; test_idx < ARRAY_SIZE(cursor_sizes); ++test_idx) -- 2.34.1

Jan. 29, 2022

[PATCH 1/2] d3d9/tests: Ignore random testbot failures in test_cursor.

by Stefan Dösinger

Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com> --- dlls/d3d9/tests/device.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c index c480a9d163e..7effd0f28b8 100644 --- a/dlls/d3d9/tests/device.c +++ b/dlls/d3d9/tests/device.c @@ -1886,11 +1886,19 @@ static void test_cursor(void) IDirect3DSurface9_Release(cursor); + /* On the testbot the cursor handle does not behave as expected in rare situations, + * leading to random test failures. Either the cursor handle changes before we expect + * it to, or it doesn't change afterwards (or already changed before we read the + * initial handle?). I was not able to reproduce this on my own machines. Moving the + * mouse outside the window results in similar behavior. However, I tested various + * obvious failure causes: Was the mouse moved? Was the window hidden or moved? Is + * the window in the background? Neither of those applies. Making the window topmost + * or using a fullscreen device doesn't improve the test's reliability either. */ memset(&info, 0, sizeof(info)); info.cbSize = sizeof(info); ok(GetCursorInfo(&info), "GetCursorInfo failed\n"); ok(info.flags & (CURSOR_SHOWING|CURSOR_SUPPRESSED), "The gdi cursor is hidden (%08x)\n", info.flags); - ok(info.hCursor == cur, "The cursor handle is %p\n", info.hCursor); /* unchanged */ + ok(info.hCursor == cur || broken(1), "The cursor handle is %p\n", info.hCursor); /* unchanged */ /* Still hidden */ ret = IDirect3DDevice9_ShowCursor(device, TRUE); @@ -1904,7 +1912,7 @@ static void test_cursor(void) info.cbSize = sizeof(info); ok(GetCursorInfo(&info), "GetCursorInfo failed\n"); ok(info.flags & (CURSOR_SHOWING|CURSOR_SUPPRESSED), "The gdi cursor is hidden (%08x)\n", info.flags); - ok(info.hCursor != cur, "The cursor handle is %p\n", info.hCursor); + ok(info.hCursor != cur || broken(1), "The cursor handle is %p\n", info.hCursor); /* Cursor dimensions must all be powers of two */ for (test_idx = 0; test_idx < ARRAY_SIZE(cursor_sizes); ++test_idx) -- 2.34.1

Jan. 29, 2022

Re: [PATCH 19/22] winhttp/tests: Avoid "misleading indentation" warnings.

by Marvin

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=106407 Your paranoid android. === w8adm (32 bit report) === winhttp: winhttp.c:301: Test failed: WinHttpSendRequest failed: 12007 winhttp.c:302: Test failed: got 12007

Jan. 29, 2022

Re: [PATCH 13/22] user32/tests: Avoid "misleading indentation" warnings.

by Marvin

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=106401 Your paranoid android. === w10pro64 (32 bit report) === user32: win.c:2392: Test failed: style 0x200000: expected !100 win.c:2392: Test failed: style 0x300000: expected !100 === w10pro64 (64 bit report) === user32: win.c:2392: Test failed: style 0x200000: expected !100 win.c:2392: Test failed: style 0x300000: expected !100 === w10pro64_zh_CN (64 bit report) === user32: win.c:10385: Test failed: pos = 00fa00fa win.c:10389: Test failed: pos = 00fa00fa win.c:10393: Test failed: pos = 00fa00fa

Jan. 29, 2022

Re: [PATCH 12/22] taskschd/tests: Avoid "misleading indentation" warnings.

by Marvin

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=106400 Your paranoid android. === w7u_adm (32 bit report) === taskschd: scheduler.c:790: Test failed: DeleteTask error 0x80070005 scheduler.c:786: Test failed: 1: expected 0, got 0x800700b7 scheduler.c:786: Test failed: 2: expected 0x80070002, got 0 scheduler.c:790: Test failed: DeleteTask error 0x80070005 scheduler.c:790: Test failed: DeleteTask error 0x80070005 scheduler.c:806: Test failed: RegisterTask error 0x800700b7 scheduler.c:941: Test failed: DeleteTask error 0x80070005 scheduler.c:943: Test failed: DeleteTask error 0x80070005 scheduler.c:946: Test failed: expected ERROR_FILE_NOT_FOUND, got 0x80070005

Jan. 29, 2022

Re: [PATCH 10/22] shell32/tests: Avoid "misleading indentation" warnings.

by Marvin

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=106398 Your paranoid android. === w1064v1809 (32 bit report) === shell32: shlfolder.c:4910: Test failed: MKDIR: expected notification type 8, got: 40000 shlfolder.c:4917: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) === w1064_tsign (32 bit report) === shell32: shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 40000) === w10pro64 (32 bit report) === shell32: shlfolder.c:4910: Test failed: CREATE: expected notification type 2, got: 40000 shlfolder.c:4917: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 2) === w1064v1809 (64 bit report) === shell32: shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) === w1064 (64 bit report) === shell32: shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 40000) === w1064_tsign (64 bit report) === shell32: shlfolder.c:4910: Test failed: RMDIR: expected notification type 10, got: 40000 shlfolder.c:4917: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 10) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) === w10pro64 (64 bit report) === shell32: shlfolder.c:4910: Test failed: CREATE: expected notification type 2, got: 40000 shlfolder.c:4917: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 2) === w10pro64_ar (64 bit report) === shell32: shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 4000000) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 40000) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 4000000) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 4000000) shlfolder.c:4910: Test failed: CREATE: expected notification type 2, got: 40000 shlfolder.c:4917: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 2) === w10pro64_he (64 bit report) === shell32: shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 40000) === w10pro64_ja (64 bit report) === shell32: shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 4000000) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 40000) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 4000000) shlfolder.c:4910: Test failed: MKDIR: expected notification type 8, got: 4000000 shlfolder.c:4917: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4918: Test failed: Expected PIDL to be NULL shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) shlfolder.c:4910: Test failed: MKDIR: expected notification type 8, got: 40000 shlfolder.c:4917: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) === w10pro64_zh_CN (64 bit report) === shell32: shlfolder.c:4910: Test failed: RMDIR: expected notification type 10, got: 40000 shlfolder.c:4917: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 10) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3) shlfolder.c:4910: Test failed: MKDIR: expected notification type 8, got: 40000 shlfolder.c:4917: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4927: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 3)

Jan. 29, 2022