- Wine-GitLab - list.winehq.org

[PATCH 0/2] MR11081: Use _aligned_free instead of free for aligned allocations (ASan).
by Bernhard Übelacker (＠bernhardu) June 6, 2026

June 6, 2026

Followup of 6b1dfdd262 and bd24679337. ASan gets triggered by using free instead of _aligned_free. Reports can be seen here: [x86_64](https://gitlab.winehq.org/bernhardu/wine/-/jobs/273791/artifacts/br… and [x86](https://gitlab.winehq.org/bernhardu/wine/-/jobs/273791/artifacts/brows… <details> <summary>Example report:</summary> ``` ==rsaenh_test.exe==508==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x02003a10 in thread T0 #0 0x785b5acb in free /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_malloc_win.cpp:78:3 #1 0x784725fb in SymCryptCallbackFree /builds/bernhardu/wine/build64/../dlls/rsaenh/implglue.c:44:5 #2 0x7848b93a in SymCryptRsakeySetValueInternal /builds/bernhardu/wine/build64/../libs/symcrypt/lib/rsakey.c:1391:9 #3 0x7848c283 in SymCryptRsakeySetValue /builds/bernhardu/wine/build64/../libs/symcrypt/lib/rsakey.c:1411:12 #4 0x7847396a in import_public_key_impl /builds/bernhardu/wine/build64/../dlls/rsaenh/implglue.c:480:9 #5 0x784852ec in import_public_key /builds/bernhardu/wine/build64/../dlls/rsaenh/rsaenh.c:3265:11 #6 0x7847a83d in import_key /builds/bernhardu/wine/build64/../dlls/rsaenh/rsaenh.c:3504:20 #7 0x7847a642 in RSAENH_CPImportKey /builds/bernhardu/wine/build64/../dlls/rsaenh/rsaenh.c:3545:12 #8 0x7ade982a in CryptImportKey /builds/bernhardu/wine/build64/../dlls/advapi32/crypt.c:1832:6 #9 0x00401882 in test_RC4_salt /builds/bernhardu/wine/build64/../dlls/rsaenh/tests/rsaenh.c:4075:15 #10 0x0040101a in func_rsaenh /builds/bernhardu/wine/build64/../dlls/rsaenh/tests/rsaenh.c:4195:5 #11 0x0041d411 in run_test /builds/bernhardu/wine/build64/../include/wine/test.h:780:5 #12 0x0041cf2b in main /builds/bernhardu/wine/build64/../include/wine/test.h 0x02003a10 is located 16 bytes inside of 324-byte region [0x02003a00,0x02003b44) allocated by thread T0 here: #0 0x785b5bcb in malloc /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_malloc_win.cpp:87:3 #1 0x7ab7e0b3 in _aligned_offset_malloc /builds/bernhardu/wine/build64/../dlls/msvcrt/heap.c:584:12 #2 0x7ab7e138 in _aligned_malloc /builds/bernhardu/wine/build64/../dlls/msvcrt/heap.c:606:12 #3 0x784725dd in SymCryptCallbackAlloc /builds/bernhardu/wine/build64/../dlls/rsaenh/implglue.c:39:12 #4 0x7848b979 in SymCryptRsakeySetValueInternal /builds/bernhardu/wine/build64/../libs/symcrypt/lib/rsakey.c:1228:24 #5 0x7848c283 in SymCryptRsakeySetValue /builds/bernhardu/wine/build64/../libs/symcrypt/lib/rsakey.c:1411:12 #6 0x7847396a in import_public_key_impl /builds/bernhardu/wine/build64/../dlls/rsaenh/implglue.c:480:9 #7 0x784852ec in import_public_key /builds/bernhardu/wine/build64/../dlls/rsaenh/rsaenh.c:3265:11 #8 0x7847a83d in import_key /builds/bernhardu/wine/build64/../dlls/rsaenh/rsaenh.c:3504:20 #9 0x7847a642 in RSAENH_CPImportKey /builds/bernhardu/wine/build64/../dlls/rsaenh/rsaenh.c:3545:12 #10 0x7ade982a in CryptImportKey /builds/bernhardu/wine/build64/../dlls/advapi32/crypt.c:1832:6 #11 0x00401882 in test_RC4_salt /builds/bernhardu/wine/build64/../dlls/rsaenh/tests/rsaenh.c:4075:15 #12 0x0040101a in func_rsaenh /builds/bernhardu/wine/build64/../dlls/rsaenh/tests/rsaenh.c:4195:5 #13 0x0041d411 in run_test /builds/bernhardu/wine/build64/../include/wine/test.h:780:5 #14 0x0041cf2b in main /builds/bernhardu/wine/build64/../include/wine/test.h SUMMARY: AddressSanitizer: bad-free /builds/bernhardu/wine/build64/../dlls/rsaenh/implglue.c:44:5 in SymCryptCallbackFree ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11081

3 4

[PATCH v3 0/1] MR10108: ntdll: Never use CLOCK_REALTIME_COARSE.
by William Horvath (＠whrvt) June 6, 2026

June 6, 2026

This is required for deterministic timekeeping, as the CLOCK_REALTIME_COARSE path depends on the scheduling tickrate (CONFIG_HZ) the kernel was built with. Increasing the kernel tickrate to 1000 or greater will then result in decreased accuracy for anything calling NtQuerySystemTime, which some anti-cheat/DRM schemes are unhappy about (see wine bug). Being in the vDSO, clock_gettime(CLOCK_REALTIME) should not meaningfully impact performance when compared to CLOCK_REALTIME_COARSE. Furthermore, the CLOCK_REALTIME_COARSE code path is completely untested in CI, because the current CI runners are configured with CONFIG_HZ < 1000. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59420 -- v3: ntdll: Never use CLOCK_REALTIME_COARSE. https://gitlab.winehq.org/wine/wine/-/merge_requests/10108

2 1

[PATCH 0/1] MR11079: cmd: Add wildcard expansion for arguments to the type program
by Barath Kannan (＠barath_kannan) June 6, 2026

June 6, 2026

Fixes https://bugs.winehq.org/show_bug.cgi?id=59816 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11079

2 2

[PATCH 0/1] MR11080: dsound/tests: Don't fail test if device cannot be opened the second time.
by Bernhard Übelacker (＠bernhardu) June 6, 2026

June 6, 2026

Followup of fc627e04d3 and ebc31cfbee. Since 2026-05-13 (or the day before) there is a single failure with the linux testbot VMs showing: ``` dsound.c:330: Test failed: DirectSoundCreate() failed: 8889000a ``` I could this reproduce inside a minimal Debian bookworm VM, after stopping pulseaudio: ``` systemctl --user stop pulseaudio.service pulseaudio.socket ``` Is there a better way to detect alsa not being able to open multiple times, and base skipping the test on this? CC: @jonkoops [Test pattern page dsound:dsound](https://test.winehq.org/data/patterns.html#dsound:dsound) [Test pattern page dsound:dsound8](https://test.winehq.org/data/patterns.html#dsound:dsound8) [Testbot run with dsound part of this patch](https://testbot.winehq.org/JobDetails.pl?Key=163251) [Testbot run with dsound part of this patch](https://testbot.winehq.org/JobDetails.pl?Key=163252) <details> <summary>Backtrace where the error AUDCLNT_E_DEVICE_IN_USE gets set</summary> ``` Thread 1 "dsound_test.exe" hit Breakpoint 2.1, alsa_open_device (alsa_name=0x7ffffe926140 "plughw:0,0", flow=<optimized out>, pcm_handle=pcm_handle@entry=0x7ffffe10fbb8, hw_params=hw_params@entry=0x7ffffe10fbb0) at .../wine/dlls/winealsa.drv/alsa.c:593 593 WARN("Unable to open PCM \"%s\": %d (%s)\n", alsa_name, err, snd_strerror(err)); (gdb) list 588 else 589 return E_UNEXPECTED; 590 591 err = snd_pcm_open(pcm_handle, alsa_name, pcm_stream, SND_PCM_NONBLOCK); 592 if(err < 0){ 593 WARN("Unable to open PCM \"%s\": %d (%s)\n", alsa_name, err, snd_strerror(err)); 594 switch(err){ 595 case -EBUSY: 596 return AUDCLNT_E_DEVICE_IN_USE; 597 default: (gdb) print err $1 = -16 (gdb) source .../wine/tools/gdbunwind.py (gdb) bt #0 alsa_open_device (alsa_name=0x7ffffe926140 "plughw:0,0", flow=<optimized out>, pcm_handle=pcm_handle@entry=0x7ffffe10fbb8, hw_params=hw_params@entry=0x7ffffe10fbb0) at .../wine/dlls/winealsa.drv/alsa.c:593 #1 0x00007f671ab48e2e in alsa_get_mix_format (args=0x7ffffe30f390) at .../wine/dlls/winealsa.drv/alsa.c:1937 #2 0x00007f671ef69c8a in __wine_unix_call_dispatcher () from .../obj/dlls/ntdll/ntdll.so #3 0x00006ffffcaebd6a in __wine_unix_call (args=0x7ffffe30f3a0, code=16, handle=<optimized out>) at .../wine/include/wine/unixlib.h:297 #4 wine_unix_call (args=0x7ffffe30f3a0, code=16) at .../wine/dlls/mmdevapi/mmdevapi_private.h:117 #5 client_GetMixFormat (iface=0x7ffffe928260, pwfx=0x7ffffe30f430) at .../wine/dlls/mmdevapi/client.c:881 #6 0x00006ffffd8c58f6 in IAudioClient_GetMixFormat (ppDeviceFormat=0x7ffffe30f470, This=<optimized out>) at include/audioclient.h:409 #7 DSOUND_WaveFormat (wfx=<synthetic pointer>, forcewave=0, client=<optimized out>, device=0x7ffffe928040) at .../wine/dlls/dsound/primary.c:129 #8 DSOUND_ReopenDevice (device=0x7ffffe928040, forcewave=forcewave@entry=0) at .../wine/dlls/dsound/primary.c:290 #9 0x00006ffffd8cc155 in DirectSoundDevice_Initialize (lpcGUID=<optimized out>, ppDevice=<optimized out>) at .../wine/dlls/dsound/dsound.c:280 #10 IDirectSound8Impl_Initialize (iface=0x7ffffe926648, lpcGuid=<optimized out>) at .../wine/dlls/dsound/dsound.c:866 #11 0x00006ffffd8c7b88 in DirectSoundCreate (lpcGUID=lpcGUID@entry=0x7ffffe926490, ppDS=0x7ffffe30f6b0, ppDS@entry=0x7ffffe30f6d0, pUnkOuter=pUnkOuter@entry=0x0) at .../wine/dlls/dsound/dsound.c:988 #12 0x0000000140021920 in test_dsound (lpGuid=lpGuid@entry=0x7ffffe926490) at .../wine/dlls/dsound/tests/dsound.c:329 #13 0x000000014000d14b in dsenum_callback (lpGuid=0x7ffffe926490, lpcstrDescription=0x7ffffe9264c0 "Speakers (Out: HDA Intel - Generic Analog)", lpcstrModule=0x7ffffe926540 "{0.0.0.00000000}.{0AE1A760-0EE4-4313-B9B0-9AD613E8DF6B}", lpContext=<optimized out>) at .../wine/dlls/dsound/tests/dsound.c:2006 #14 0x00006ffffd8d6156 in a_to_w_callback (guid=0x7ffffe926490, descW=<optimized out>, modW=0x7ffffe33bd80 L"\173\060\056\060\056\060\056\060\060\060\060\060\060\060\060\175\056\173\060\101\105\061\101\067\066\060\055\060\105\105\064\055\064\063\061\063\055\102\071\102\060\055\071\101\104\066\061\063\105\070\104\106\066\102", <incomplete sequence \175>, data=0x7ffffe30fc00) at .../wine/dlls/dsound/dsound_main.c:298 #15 0x00006ffffd8d9488 in send_device (device=0x7ffffe336e30, guid=guid@entry=0x7ffffe926490, cb=cb@entry=0x6ffffd8d6020 <a_to_w_callback>, user=0x7ffffe30fc00, user@entry=0x7ffffe30fc28) at .../wine/dlls/dsound/dsound_main.c:427 #16 0x00006ffffd8d6f6f in enumerate_mmdevices (flow=flow@entry=eRender, guids=0x7ffffe926480, cb=cb@entry=0x6ffffd8d6020 <a_to_w_callback>, user=0x7ffffe30fc28, user@entry=0x7ffffe30fc00) at .../wine/dlls/dsound/dsound_main.c:508 #17 0x00006ffffd8c81ac in DirectSoundEnumerateW (lpDSEnumCallback=lpDSEnumCallback@entry=0x6ffffd8d6020 <a_to_w_callback>, lpContext=lpContext@entry=0x7ffffe30fc00) at .../wine/dlls/dsound/dsound_main.c:552 #18 0x00006ffffd8c8135 in DirectSoundEnumerateA (lpDSEnumCallback=lpDSEnumCallback@entry=0x14000d0e0 <dsenum_callback>, lpContext=lpContext@entry=0x0) at .../wine/dlls/dsound/dsound_main.c:332 #19 0x0000000140014818 in dsound_tests () at .../wine/dlls/dsound/tests/dsound.c:2032 #20 func_dsound () at .../wine/dlls/dsound/tests/dsound.c:2257 #21 0x00000001400185c3 in run_test (name=0x7ffffe33e7cf "dsound") at .../wine/include/wine/test.h:780 #22 main (argc=<optimized out>, argv=<optimized out>) at .../wine/include/wine/test.h:900 (gdb) ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11080

2 1

[PATCH v4 0/2] MR9299: ole32, combase: Add tests for COM context switching and delayed marshaling.
by Vibhav Pant (＠vibhavp) June 6, 2026

June 6, 2026

When `RoGetAgileReference` is used with `AGILEREFERENCE_DELAYEDMARSHAL`, the returned `IAgileReference` also contains a reference to the apartment the object belongs to. Thus, when `IAgileReference::Resolve()` gets called, the object will get marshaled inside the owning apartment, not the caller's apartment. This seems to be made possible by the `IContextCallback` interface. It provides a way to (ab)use the marshaller to execute arbitrary code inside a COM context, which is an additional bit of state nested inside apartments. An apartment can contain multiple COM contexts, and the standard marshaller will keep track of which context a marshaled interface is bound to. All method calls through that marshalled pointer will be wrapped around a context-switch, even when the caller is in the same apartment. Additionally, creating an instance of the class `CLSID_IContextCallback` allows us to create new contexts inside an apartment. C++/WinRT makes use of `IContextCallback` to [implement support for C++ coroutines ](https://github.com/microsoft/cppwinrt/blob/ebace4abb8f48b6b9a612e8b84667e6044976a47/strings/base_coroutine_threadpool.h#L51)(co_await, et al) inside application STA code. Another use of COM contexts seems to be the UI code in WinRT applications, where certain objects can only be `Released`/destructed from the apartment they were created in. (I was able to find another instance of `IContextCallback` usage in the wild [here](https://github.com/Open-Shell/Open-Shell-Menu/blob/4ebeadd949d0550642…, to get an `IAccessible` implementation that has apartment-affinity). -- v4: ole32/tests: Add tests for IContextCallback::ContextCallback and CoDisconnectContext. combase/tests: Add tests for delayed marshaling of objects with apartment affinity. https://gitlab.winehq.org/wine/wine/-/merge_requests/9299

3 4

Re: [PATCH 0/0] MR11078: cmd: Add wildcard expansion for arguments to the 'type' builtin utility. - closed
by Barath Kannan (＠barath_kannan) June 6, 2026

June 6, 2026

This merge request was closed by Barath Kannan. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11078

1 0

[PATCH 0/1] MR11077: ntdll: Preserve nonvolatile registers across VEH callbacks.
by Soham Nandy (＠natimerry) June 6, 2026

June 6, 2026

Some VEH pop / modify nonvolatile registers before returning. This is a violation of the calling convention and leaves stale values after the VEH is called. Call VEHs through a wrapper which saves and restores non volatile registers around the callback. This is modified and split up form https://gitlab.winehq.org/wine/wine/-/merge_requests/11069. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11077

2 1

[PATCH v2 0/2] MR11076: msxml3: Invoke onreadystatechange after a successful synchronous load.
by Rose Hellsing (＠axtlos) June 5, 2026

June 5, 2026

Native MSXML fires the onreadystatechange handler synchronously from within IXMLDOMDocument::load()/loadXML() once parsing completes and readyState reaches 4. Hosts that set the handler before calling load() and expect it to have run by the time control returns to the caller rely on this ordering; Wine currently invokes the handler only as part of the asynchronous parse path, so synchronous loads silently skip it. This is MR 1 out of 4 for https://bugs.winehq.org/show_bug.cgi?id=33474 -- v2: msxml3/tests: Test synchronous invocation of onreadystatechange from loadXML(). msxml3: Invoke onreadystatechange after a successful synchronous load. https://gitlab.winehq.org/wine/wine/-/merge_requests/11076

2 2

Re: [PATCH v4 0/2] MR10952: riched20: Properly capture \pntext content
by Rose Hellsing (＠axtlos) June 5, 2026

June 5, 2026

@huw could you take a look at this? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10952#note_142322

1 0

[PATCH 0/2] MR11076: msxml3: Invoke onreadystatechange after a successful synchronous load.
by Rose Hellsing (＠axtlos) June 5, 2026

June 5, 2026

Native MSXML fires the onreadystatechange handler synchronously from within IXMLDOMDocument::load()/loadXML() once parsing completes and readyState reaches 4. Hosts that set the handler before calling load() and expect it to have run by the time control returns to the caller rely on this ordering; Wine currently invokes the handler only as part of the asynchronous parse path, so synchronous loads silently skip it. This is MR 1 out of 4 for https://bugs.winehq.org/show_bug.cgi?id=33474 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11076

2 2