In my last ASan run below report showed up.
Maybe manifests also as crashes in https://test.winehq.org/data/patterns.html#setupapi:diskspace
Contains also a little patch reversing the message in two `ok` statements.
```
=================================================================
==setupapi_test.exe==3900==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0xbebebebe in thread T0
#0 0x7a102bdb in free /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:71:3
#1 0x78a6311c in SetupDestroyDiskSpaceList .../wine/dlls/setupapi/diskspace.c:246:5
#2 0x0042572a in test_SetupDuplicateDiskSpaceListA .../wine/dlls/setupapi/tests/diskspace.c:216:8
#3 0x00424ab1 in func_diskspace .../wine/dlls/setupapi/tests/diskspace.c:765:5
#4 0x0044f493 in run_test .../wine/include/wine/test.h:765:5
#5 0x0044f035 in main .../wine/include/wine/test.h:884:12
#6 0x004506de in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:58:11
#7 0x7bcc0f0f in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x7b820f0f)
#8 0x7be31dc2 in call_thread_func_wrapper (C:\windows\system32\ntdll.dll+0x7bc41dc2)
#9 0x7be326c9 in call_thread_func .../wine/dlls/ntdll/signal_i386.c:524:9
Address 0xbebebebe is a wild pointer inside of access range of size 0x00000001.
SUMMARY: AddressSanitizer: bad-free .../wine/dlls/setupapi/diskspace.c:246:5 in SetupDestroyDiskSpaceList
```
Testbot run with this two patches: https://testbot.winehq.org/JobDetails.pl?Key=151644
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7501
--
v2: wined3d: Create a Vulkan video session backing the wined3d_decoder_vk.
wined3d: Look for a video decode queue.
d3d11: Create a wined3d_decoder object backing the d3d11 decoder object.
wined3d: Introduce a Vulkan decoder backend.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7480
Many applications request and use GL configs with alpha, but assume that
the windowing system will present their surfaces opaquely. Wayland
compositors normally respect the alpha channel, which leads to unwanted
translucency effects for such applications, so we use the
EGL_EXT_present_opaque extension to avoid this.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57800
--
Note that this has been a known issue since the initial GL support in winewayland (see description of https://gitlab.winehq.org/wine/wine/-/merge_requests/5264). At that point I didn't enable the opaque attribute because there was a bug in Mesa that could cause a crash for some 16bpp formats. I fixed the bug in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28153, and the fix got released in 24.2.0 (Aug 2024). This Mesa version (or newer) is now either part of the latest version of most major distributions or available through official updates/backports (from what I see OpenSUSE Leap is a notable exception), so I now feel more comfortable enabling the attribute by default. Some users using older Mesa versions may be affected, but I think most people trying out the latest Wine 10.x will already be (or can move to) to newer Mesa versions anyway.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7500