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

Re: [PATCH v3 0/9] MR272: d3dx10: Add D3DX10CreateThreadPump implementation.

by Piotr Caban (＠piotr)

On Mon Jun 20 15:42:37 2022 +0000, Francois Gouget wrote: > I don't see any case where d3dx10_43:d3dx10 crashed in WineTest: > https://test.winehq.org/data/patterns.html#d3dx10_43:d3dx10 > So it does look like this patchset introduces a new failure. It crashed in v1 (due to leak in check_resource_data). It's already fixed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/272#note_2369

June 20, 2022

Re: [PATCH v3 0/9] MR272: d3dx10: Add D3DX10CreateThreadPump implementation.

by Francois Gouget (＠fgouget)

On Sat Jun 18 12:13:35 2022 +0000, **** wrote: > Marvin replied on the mailing list: > ``` > Hi, > It looks like your patch introduced the new failures shown below. > Please investigate and fix them before resubmitting your patch. > If they are not new, fixing them anyway would help a lot. Otherwise > please ask for the known failures list to be updated. > The full results can be found at: > https://testbot.winehq.org/JobDetails.pl?Key=117237 > Your paranoid android. > === debian11 (32 bit report) === > d3dx10_43: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (0x70bb0040). > === debian11 (32 bit Arabic:Morocco report) === > d3dx10_43: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (0x70bb0040). > === debian11 (32 bit German report) === > d3dx10_43: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (0x70bb0040). > === debian11 (32 bit French report) === > d3dx10_43: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (0x70bb0040). > === debian11 (32 bit Hebrew:Israel report) === > d3dx10_43: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (0x70bb0040). > === debian11 (32 bit Hindi:India report) === > d3dx10_43: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (0x70bb0040). > === debian11 (32 bit Japanese:Japan report) === > d3dx10_43: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (0x70bb0040). > === debian11 (32 bit Chinese:China report) === > d3dx10_43: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (0x70bb0040). > === debian11 (32 bit WoW report) === > d3dx10_43: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (0x70bb0040). > ``` I don't see any case where d3dx10_43:d3dx10 crashed in WineTest: https://test.winehq.org/data/patterns.html#d3dx10_43:d3dx10 So it does look like this patchset introduces a new failure. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/272#note_2368

June 20, 2022

Re: [PATCH v3 1/6] comctl32/tests: Expand ownerdata listview tests.

by Zhiyi Zhang

On 6/20/22 05:51, Angelo Haller wrote: > On 18/06/2022 21.34, Zhiyi Zhang wrote: >> >> On 6/19/22 01:24, Angelo Haller wrote: >>> On 17/06/2022 22.37, Marvin wrote: >>>> Hi, >>>> >>>> It looks like your patch introduced the new failures shown below. >>>> Please investigate and fix them before resubmitting your patch. >>>> If they are not new, fixing them anyway would help a lot. Otherwise >>>> please ask for the known failures list to be updated. >>>> >>>> The full results can be found at: >>>> https://testbot.winehq.org/JobDetails.pl?Key=117220 >>>> >>>> Your paranoid android. >>>> >>>> >>>> === debian11 (32 bit report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37148 bytes) >>>> >>>> === debian11 (32 bit Arabic:Morocco report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37148 bytes) >>>> >>>> === debian11 (32 bit German report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37148 bytes) >>>> >>>> === debian11 (32 bit French report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37148 bytes) >>>> >>>> === debian11 (32 bit Hebrew:Israel report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37148 bytes) >>>> >>>> === debian11 (32 bit Hindi:India report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37148 bytes) >>>> >>>> === debian11 (32 bit Japanese:Japan report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37148 bytes) >>>> >>>> === debian11 (32 bit Chinese:China report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37148 bytes) >>>> >>>> === debian11 (32 bit WoW report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37148 bytes) >>>> >>>> === debian11 (64 bit WoW report) === >>>> >>>> Report validation errors: >>>> comctl32:listview prints too much data (37388 bytes) >>> Is there anything I can or need to do about this? These seem like false positives. >>> >>> >> Currently TestBots have a 32k log size limit. Try to reduce the log messages a bit. You can submit your tests at https://testbot.winehq.org/ before submitting to the wine-devel mailing list > > I see. How can I reduce log messages though? Short of removing tests? > > As can be seen in the series, the test do start to succeed as of patch 5/6. So the failure is only introduced due to wine_todo sequences being logged to the terminal. I am not generating any additional log messages. > In this case, you can move the tests into the same patch or after the patch that fixes the bug.

June 20, 2022

Re: [PATCH 1/2] ntdll/tests: Test for setting x86 / x64 EFLAGS register in context.

by Francois Gouget

On Mon, 20 Jun 2022, Marvin wrote: [...] > === w7u_2qxl (32 bit report) === > === w8 (32 bit report) === > > ntdll: > exception.c:10725: Test failed: Expected EFlags to be 0x3f0fd7, got 0x3f4fd7 > exception.c:10733: Test failed: Expected EFlags to be 0x3f0fd7, got 0x200 > exception.c:10725: Test failed: Expected EFlags to be 0x3f0fd7, got 0x3f4fd7 > exception.c:10733: Test failed: Expected EFlags to be 0x3f0fd7, got 0x200 As far as I can tell these are indeed new failures. So it looks like this patch needs to be tweaked to work on Windows 7 and 8. -- Francois Gouget <fgouget(a)codeweavers.com>

June 20, 2022

Re: [PATCH 3/7] win32u: Move WM_WINDOWPOSCHANGED implementation from user32.

by Francois Gouget

On Mon, 20 Jun 2022, Marvin wrote: [...] > === debian11 (32 bit Chinese:China report) === > > user32: > win.c:11787: Test failed: 011D00CE: expected NOT topmost > win.c:11606: Test succeeded inside todo block: 5: hwnd 00C00042 is still topmost This is a preexisting pair of failures but the window handles prevent them from being recognized as such. It's actually part of a group of 7 failures: https://bugs.winehq.org/show_bug.cgi?id=53206 I also added it to the TestBot's list of known failures: https://testbot.winehq.org/FailureDetails.pl?Key=139 -- Francois Gouget <fgouget(a)codeweavers.com>

June 20, 2022

Re: [PATCH 5/7] win32u: Move WM_PRINT implementation from user32.

by Francois Gouget

On Mon, 20 Jun 2022, Marvin wrote: [...] > === debian11 (64 bit WoW report) === > > user32: > input.c:2870: Test failed: 15: expected WM_INPUT message > input.c:2873: Test failed: 15: expected RIM_INPUT message This is a preexisting pair of failures: https://bugs.winehq.org/show_bug.cgi?id=53205 I also added it to the TestBot's list of known failures: http://winetestbot.dolphin/FailureDetails.pl?Key=138 -- Francois Gouget <fgouget(a)codeweavers.com>

June 20, 2022

Re: [PATCH 0/7] MR285: win32u: Default window proc conversion - approved

by Huw Davies (＠huw)

This merge request was approved by Huw Davies. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/285

June 20, 2022

Re: [PATCH 0/3] MR263: iphlpapi: Implement GetBestRoute2.

by Huw Davies (＠huw)

Looking back at my nsiproxy notes, I did partially reverse this one (mainly because it turns out to be table 0, so it was the first of the IP tables that I looked at). For IPv4, the key is 8 UINTs long, with the dest addr in the 2nd UINT. I guess the NET_LUID would also be sent along with any src address (although we could leave those as undetermined for now). You'd want to call `NsiGetAllParameters()` and retrieve the `dynamic` table. It has the size of 26 UINTs: the prefix is in the 2nd, the prefix length in the 3rd, next hop is in the 11th. Many other properties can easily be found by comparing with the result of `GetBestRoute2()`. I'd suggest testing with localhost as well as a remote addr. I didn't put much effort into IPv6, save that the key size is 14 UINTs i.e. 6 more than IPv4 (which makes sense if there are two addresses), and the dynamic table is 38 UINTs. So with all that, it probably makes sense to implement this in `nsiproxy.sys`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/263#note_2363

June 20, 2022

Re: [PATCH v3 0/2] MR244: winex11.drv: Keep GLX pbuffer alive while its drawable is used

by Paul Gofman (＠gofman)

v2: - Fix typo in patch title ("sgl_drawable" -> "wgl_drawable"). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/244#note_2362

June 20, 2022

[PATCH v3 2/2] winex11.drv: Destroy GLX pbuffer when destroying drawable.

by Paul Gofman

From: Paul Gofman <pgofman(a)codeweavers.com> Signed-off-by: Paul Gofman <pgofman(a)codeweavers.com> --- dlls/winex11.drv/opengl.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c index 468d10fbbae..8d6afba9a6f 100644 --- a/dlls/winex11.drv/opengl.c +++ b/dlls/winex11.drv/opengl.c @@ -1165,6 +1165,10 @@ static void release_gl_drawable( struct gl_drawable *gl ) pglXDestroyPixmap( gdi_display, gl->drawable ); XFreePixmap( gdi_display, gl->pixmap ); break; + case DC_GL_PBUFFER: + TRACE( "destroying pbuffer drawable %lx\n", gl->drawable ); + pglXDestroyPbuffer( gdi_display, gl->drawable ); + break; default: break; } @@ -2316,7 +2320,6 @@ static BOOL X11DRV_wglDestroyPbufferARB( struct wgl_pbuffer *object ) pthread_mutex_lock( &context_mutex ); list_remove( &object->entry ); pthread_mutex_unlock( &context_mutex ); - pglXDestroyPbuffer(gdi_display, object->gl->drawable); release_gl_drawable( object->gl ); if (object->tmp_context) pglXDestroyContext(gdi_display, object->tmp_context); -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/244

June 20, 2022