- wine-gitlab - winehq.org

Re: [PATCH v2 0/1] MR7036: windowscodecs: Fix a typo in interface name. - approved
by Alexandre Julliard (＠julliard) 18 Dec '24

18 Dec '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7036

1 0

[PATCH 0/1] MR7022: configure: Add /usr/lib64/pkgconfig to the 32-bit search path.
by Elizabeth Figura (＠zfigura) 18 Dec '24

18 Dec '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53953 This is not what I would do. Bug 53953 amounts to "some users didn't install 32-bit headers, so we used the wrong ones, which are usually identical so it doesn't matter". From the perspective of using the software as intended, this is unilaterally user error. From a more utilitarian perspective, this is a regression, and ensuring that we're not using the *functionally* incorrect headers is a problem we have to solve anyway. (Cf. GStreamer, which may be the only interesting case.) On the other hand, it's a regression that's already been in two major versions. Anyone building Wine on Fedora has surely already installed the right headers by now. I'm submitting this patch in an attempt to garner a decreed resolution to the bug, one way or another, but again, this solution is not the one I would prescribe if it were my choice. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7022

5 6

[PATCH 0/1] MR7041: crypt32: Avoid stack-use-after-scope in CSignedEncodeMsg_GetParam. (ASan)
by Bernhard Übelacker (＠bernhardu) 18 Dec '24

18 Dec '24

This moves the stack variable to the outer scope, because it gets stored in the variable info and used below the call to `CRYPT_AsnEncodeCMSSignedInfo` a few lines below. ``` ================================================================= ==1032==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffffe1ff133 at pc 0x6ffff821dbd1 bp 0x7ffffe1fe700 sp 0x7ffffe1fe748 READ of size 1 at 0x7ffffe1ff133 thread T0 0430:fixme:file:server_get_file_info Unsupported info class e #0 0x6ffff821dbd0 in CRYPT_AsnEncodeOid .../wine/dlls/crypt32/encode.c:839:13 #1 0x6ffff821a98a in CRYPT_AsnEncodeSequence .../wine/dlls/crypt32/encode.c:185:15 #2 0x6ffff821e456 in CRYPT_AsnEncodePKCSContentInfoInternal .../wine/dlls/crypt32/encode.c:1942:12 #3 0x6ffff821a98a in CRYPT_AsnEncodeSequence .../wine/dlls/crypt32/encode.c:185:15 #4 0x6ffff821f3b9 in CRYPT_AsnEncodeCMSSignedInfo .../wine/dlls/crypt32/encode.c:4400:12 #5 0x6ffff82576bc in CSignedEncodeMsg_GetParam .../wine/dlls/crypt32/msg.c:1281:19 #6 0x6ffff82570a0 in CryptMsgGetParam .../wine/dlls/crypt32/msg.c:3720:12 #7 0x6ffff82570a0 in CSignedEncodeMsg_GetParam .../wine/dlls/crypt32/msg.c:1217:15 #8 0x6ffff824750e in CryptSignMessage .../wine/dlls/crypt32/message.c:508:19 #9 0x0001400e11ad in test_sign_message .../wine/dlls/crypt32/tests/message.c:1015:11 #10 0x0001400e11ad in func_message .../wine/dlls/crypt32/tests/message.c:1310:5 #11 0x00014015ecb1 in run_test .../wine/include/wine/test.h:765:5 #12 0x00014015ecb1 in main .../wine/include/wine/test.h:884:12 #13 0x000140160bbf in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:58:11 #14 0x6ffffbdc4808 in BaseThreadInitThunk .../wine/dlls/kernel32\thread.c:61:5 #15 0x6ffffad1fa1a in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17000fa1a) Address 0x7ffffe1ff133 is located in stack of thread T0 at offset 275 in frame #0 0x6ffff8256f4f in CSignedEncodeMsg_GetParam .../wine/dlls/crypt32/msg.c:1207 This frame has 5 object(s): [32, 56) 'info' (line 1215) [96, 117) 'oid_rsa_signed' (line 1228) [160, 240) 'info22' (line 1243) [272, 293) 'oid_rsa_data' (line 1249) <== Memory access at offset 275 is inside this variable [336, 352) 'blob' (line 1258) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp, SEH and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-use-after-scope .../wine/dlls/crypt32/encode.c:839:13 in CRYPT_AsnEncodeOid Shadow bytes around the buggy address: 0x7ffffe1fee80: 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 f3 f3 f3 f3 0x7ffffe1fef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffffe1fef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffffe1ff000: 00 00 00 00 f1 f1 f1 f1 f8 f8 f8 f2 f2 f2 f2 f2 0x7ffffe1ff080: f8 f8 f8 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 =>0x7ffffe1ff100: 00 00 f2 f2 f2 f2[f8]f8 f8 f2 f2 f2 f2 f2 f8 f8 0x7ffffe1ff180: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffffe1ff200: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x7ffffe1ff280: 00 00 00 f2 f2 f2 f2 f2 f8 f8 f8 f2 f2 f2 f2 f2 0x7ffffe1ff300: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 f8 f8 0x7ffffe1ff380: f8 f2 f2 f2 f2 f2 f8 f8 f3 f3 f3 f3 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==1032==ABORTING make: *** [Makefile:36953: dlls/crypt32/tests/x86_64-windows/message.ok] Fehler 1 ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7041

3 3

[PATCH 0/1] MR7039: server: Destroy global hook table in desktop_close_handle().
by Paul Gofman (＠gofman) 18 Dec '24

18 Dec '24

Commit f784374bcb5195c918754b1da6142a618a0da7dd introduced a cyclic reference between desktop and global hook through global hook table. So now if a hook was set and then not explicitly unset and the process was just terminated the hook, desktop, thread and some other related objects are leaked (which is displayed by wineserver on prefix shutdown in this case). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7039

3 3

[PATCH 0/1] MR7040: capstone: Avoid GCC being treated as old VisualStudio
by Gerald Pfeifer (＠gerald) 18 Dec '24

18 Dec '24

The preprocessor condition to cover pre-2013 VisualStudio around C99 support actually also admitted current versions of GCC and breaks GCC in C23 mode. Address this by explicitly checking for GCC which, by definition, then does not qualify as VisualStudio. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7040

4 4

[PATCH v2 0/2] MR825: winex11.drv: optimize repeated ClipCursor calls
by Jan Klötzke (＠jkloetzke) 18 Dec '24

18 Dec '24

At least Doom 64 calls ClipCursor() with identical parameters repeatedly, which seems to cause a considerable overhead. Together with high polling rate mouse input this causes the game to almost freeze while the mouse is being moved. So if the clipping did not change we can bail out early because it will not cause any observable difference anyway. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46976 Signed-off-by: Jan Klötzke <jan(a)kloetzke.net> -- v2: winex11.drv: optimize repeated ClipCursor calls winex11.drv: create win32 clipping window only once https://gitlab.winehq.org/wine/wine/-/merge_requests/825

5 8

[PATCH 0/1] MR7038: d3dx9_36/tests: Fix logging of expected bytes in check_vertex_components. (ASan)
by Bernhard Übelacker (＠bernhardu) 17 Dec '24

17 Dec '24

This appeared by running tests with PE-side ASan enabled. ``` ================================================================= ==1116==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffffe1f8794 at pc 0x00014015dd3b bp 0x7ffffe1ef9b0 sp 0x7ffffe1ef9f8 READ of size 2 at 0x7ffffe1f8794 thread T0 04a0:fixme:file:server_get_file_info Unsupported info class e #0 0x00014015dd3a in check_vertex_components .../wine/dlls/d3dx9_36/tests/mesh.c:6858:137 #1 0x0001401173ef in test_weld_vertices .../wine/dlls/d3dx9_36/tests/mesh.c:8702:13 #2 0x0001401173ef in func_mesh .../wine/dlls/d3dx9_36/tests/mesh.c:11869:5 #3 0x000140224057 in run_test .../wine/include/wine/test.h:765:5 #4 0x000140224057 in main .../wine/include/wine/test.h:884:12 #5 0x000140225faf in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:58:11 #6 0x6ffffbfd4808 in BaseThreadInitThunk .../wine/dlls/kernel32\thread.c:61:5 #7 0x6ffffacefa1a in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17000fa1a) Address 0x7ffffe1f8794 is located in stack of thread T0 at offset 35796 in frame #0 0x0001400ead6f in func_mesh .../wine/dlls/d3dx9_36/tests/mesh.c:11843 This frame has 590 object(s): [32, 104) 'adjacency.i2700' (line 11782) [144, 216) 'adjacency_out.i' (line 11782) [256, 264) 'buffer.i' (line 11785) [288, 296) 'mesh.i2701' (line 11786) [320, 328) 'data.i' (line 11790) [352, 872) 'declaration.i2526' (line 11593) ... [34928, 34952) 'adjacency23.i' (line 7796) [34992, 35072) 'exp_vertices23.i' (line 7797) [35104, 35128) 'exp_indices23.i' (line 7806) [35168, 35176) 'exp_face_remap23.i' (line 7807) [35200, 35224) 'exp_vertex_remap23.i' (line 7808) [35264, 35384) 'vertices24.i' (line 7811) [35424, 35448) 'indices24.i' (line 7821) [35488, 35496) 'attributes24.i' (line 7822) [35520, 35588) 'epsilons24.i' (line 7826) [35632, 35656) 'adjacency24.i' (line 7827) [35696, 35796) 'exp_vertices24.i' (line 7828) <== Memory access at offset 35796 overflows this variable [35840, 35864) 'exp_indices24.i' (line 7837) [35904, 35912) 'exp_face_remap24.i' (line 7838) [35936, 35960) 'exp_vertex_remap24.i' (line 7839) [36000, 36120) 'vertices25.i' (line 7844) [36160, 36184) 'indices25.i' (line 7854) [36224, 36232) 'attributes25.i' (line 7855) [36256, 36324) 'epsilons25.i' (line 7859) [36368, 36392) 'adjacency25.i' (line 7860) [36432, 36532) 'exp_vertices25.i' (line 7861) [36576, 36600) 'exp_indices25.i' (line 7870) [36640, 36648) 'exp_face_remap25.i' (line 7871) ... [57216, 57276) 'vertex.i27' (line 536) [57312, 57316) 'got_rad.i' (line 537) [57328, 57340) 'got_max.i' (line 469) [57360, 57372) 'got_min.i' (line 469) [57392, 57452) 'vertex.i' (line 469) [57488, 57500) 'bottom_point.i' (line 376) [57520, 57532) 'center.i' (line 376) [57552, 57564) 'top_point.i' (line 376) [57584, 57596) 'raydirection.i' (line 376) [57616, 57628) 'rayposition.i' (line 376) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp, SEH and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow .../wine/dlls/d3dx9_36/tests/mesh.c:6858:137 in check_vertex_components Shadow bytes around the buggy address: 0x7ffffe1f8500: f2 f2 f2 f2 00 f2 f2 f2 00 00 00 f2 f2 f2 f2 f2 0x7ffffe1f8580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 0x7ffffe1f8600: f2 f2 f2 f2 00 00 00 f2 f2 f2 f2 f2 00 f2 f2 f2 0x7ffffe1f8680: 00 00 00 00 00 00 00 00 04 f2 f2 f2 f2 f2 00 00 0x7ffffe1f8700: 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 =>0x7ffffe1f8780: 00 00[04]f2 f2 f2 f2 f2 00 00 00 f2 f2 f2 f2 f2 0x7ffffe1f8800: 00 f2 f2 f2 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 0x7ffffe1f8880: 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 0x7ffffe1f8900: 00 00 00 f2 f2 f2 f2 f2 00 f2 f2 f2 00 00 00 00 0x7ffffe1f8980: 00 00 00 00 04 f2 f2 f2 f2 f2 00 00 00 f2 f2 f2 0x7ffffe1f8a00: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 04 f2 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==1116==ABORTING 04a0:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 00007FFFFEA8FE80 make: *** [Makefile:106354: dlls/d3dx9_36/tests/x86_64-windows/mesh.ok] Fehler 1 ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7038

2 1

[PATCH 0/1] MR7036: windowscodecs: Fix a typo in interface name.
by Nikolay Sivov (＠nsivov) 17 Dec '24

17 Dec '24

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7036

3 2

Re: [PATCH v3 0/1] MR7016: winex11.drv: Use NtUserReleaseDC() with hdc in X11DRV_vulkan_surface_presented(). - approved
by Alexandre Julliard (＠julliard) 17 Dec '24

17 Dec '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7016

1 0

Re: [PATCH v5 0/1] MR6993: msxml3: Correct looping of Document Element node map. - approved
by Alexandre Julliard (＠julliard) 17 Dec '24

17 Dec '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6993

1 0

2025

2024

2023

2022

wine-gitlab