April 2025 - Wine-Devel - list.winehq.org

Re: How to use AddressSanitizer with Wine?

by Alex Henrie

On Sat, Apr 26, 2025 at 4:36 PM Bernhard Übelacker <bernhardu(a)mailbox.org> wrote: > For enabling ASan(PE) I collected some "notes to myself", which I hope > are enough accurate to enable someone else to reproduce the results. > [6] https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-04-05_wine-10.… Thank you for sharing! Goodness, it's a lot more complicated than I had hoped. Notwithstanding the difficulty, following your instructions closely I was able to build and run Wine with the llvm-mingw AUR package.[1] My LLVM variables look like this: export LLVM_INST_PATH=/opt/llvm-mingw export x86_64_LLVM_CLANG_RT_LIB=$(find $LLVM_INST_PATH -name libclang_rt.asan_dynamic-x86_64.dll.a) export i386_LLVM_CLANG_RT_LIB=$(find $LLVM_INST_PATH -name libclang_rt.asan_dynamic-i386.dll.a) For my own sanity, I created scripts named configure64.sh, build64.sh, configure32.sh, build32.sh, and run.sh for the various steps of the instructions. I think it would be a lot easier to use your ASan branch if the commands were already in scripts. > Unfortunately I have one patch with LLVM still in progress, > therefore a self-built LLVM would be needed, to build wine. > But this is just needed for HEAP_REALLOC_IN_PLACE_ONLY re-allocations, > and running with "windows_hook_rtl_allocators=0" should not be affected by this, > and that way building wine from the plain nightly llvm-mingw package should work. Could you note that in the README please? Upstream llvm-mingw combined with windows_hook_rtl_allocators=1 resulted in the cryptic error "wine: could not load kernel32.dll, status c0000135" when trying to initialize and use the Wine prefix. I ran a few parts of the Wine test suite and I've submitted my first patch based on the results.[2] Furthermore, since the instructions in the wiki were outdated and nonfunctional, I've replaced them with a link to your repository.[3] Thanks very much for all the work you put into it! -Alex [1] https://aur.archlinux.org/packages/llvm-mingw [2] https://gitlab.winehq.org/wine/wine/-/merge_requests/7925 [3] https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#memory--address-c…

April 28, 2025

Re: How to use AddressSanitizer with Wine?

by Bernhard Übelacker

Hello Alex, Am 26.04.25 um 23:18 schrieb Alex Henrie: > Dear oenologists, > > I would like to use GCC's AddressSanitizer [1] to investigate a memory > corruption bug in Wine. There must be a way to do it because I see > multiple references to "ASan" in the Wine commit log in commits from > this year.[2] I found some instructions on the WineHQ wiki,[3] but I > get a myriad of linker errors when I try to follow them. > > What Linux distributions can successfully compile Wine with libasan? > Are there special steps not mentioned in the wiki? Does > AddressSanitizer work with MinGW, or only with non-PE builds? > > I'd love to get AddressSanitizer working myself, but even if I can't, > thanks to Bernhard and Nikolay for using it to fix a lot of bugs > already. > > -Alex > > [1] https://github.com/google/sanitizers/wiki/AddressSanitizer > [2] https://gitlab.winehq.org/wine/wine/-/commits/master?search=ASan > [3] https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#memory--address-c… Thanks for asking, I fear I should have provide this information long time ago. I fear GCC is not able to achieve this on PE side currently. The wiki references may be just for the Unix side of things. A few months ago I felt brave and tried to get some changes into llvm-project about function interception, and that went better than I had hoped. So I found Martin Storsjö's llvm-mingw, and building wine with it works well. As a side project I tried to build wine with ASan(PE-side) enabled, and this worked (with currently plenty of hacks) also quite well. For enabling ASan(PE) I collected some "notes to myself", which I hope are enough accurate to enable someone else to reproduce the results. Currently I try to push my current state for each wine release, like in [7]. In [8][9] is the output when running the conformance test suite from such an ASan(PE) enabled tree. Thanks to Nikolay some of the issues could be fixed immediately. Unfortunately I have one patch with LLVM still in progress, therefore a self-built LLVM would be needed, to build wine. But this is just needed for HEAP_REALLOC_IN_PLACE_ONLY re-allocations, and running with "windows_hook_rtl_allocators=0" should not be affected by this, and that way building wine from the plain nightly llvm-mingw package should work. This notes might be better placed in the wiki, but I currently don't know how is the best way to enter it there. Please let me know any issues or uncertainties in my description. Kind regards, Bernhard [4] https://bugs.winehq.org/show_bug.cgi?id=50993 [5] https://bugs.winehq.org/show_bug.cgi?id=52386 [6] https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-04-05_wine-10.… [7] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-04-05_wine-10.… [8] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-04-05_wine-10.… [9] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-04-05_wine-10.…

April 26, 2025

How to use AddressSanitizer with Wine?

by Alex Henrie

Dear oenologists, I would like to use GCC's AddressSanitizer [1] to investigate a memory corruption bug in Wine. There must be a way to do it because I see multiple references to "ASan" in the Wine commit log in commits from this year.[2] I found some instructions on the WineHQ wiki,[3] but I get a myriad of linker errors when I try to follow them. What Linux distributions can successfully compile Wine with libasan? Are there special steps not mentioned in the wiki? Does AddressSanitizer work with MinGW, or only with non-PE builds? I'd love to get AddressSanitizer working myself, but even if I can't, thanks to Bernhard and Nikolay for using it to fix a lot of bugs already. -Alex [1] https://github.com/google/sanitizers/wiki/AddressSanitizer [2] https://gitlab.winehq.org/wine/wine/-/commits/master?search=ASan [3] https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#memory--address-c…

April 26, 2025

Announcing WineConf 2025

by Alexandre Julliard

Folks, It's been a while, so it's time for another WineConf! Given that a large proportion of the Wine devs are working for CodeWeavers, we thought that we'd do WineConf right after our annual company meeting, to take advantage of most people being in town already. So the plan is to hold WineConf on Saturday September 27, 2025. The location is The Hague, Netherlands. In fact it will be the exact same venue as WineConf 2018, which I'm sure many of you remember fondly ;-) You can find all the details here: https://gitlab.winehq.org/wine/wine/-/wikis/WineConf/WineConf-2025 Please note that we ask people to register so that we can get a headcount for the hotel. Attending is free of charge, and travel sponsorship is available. Looking forward to seeing many of you there! -- Alexandre Julliard julliard(a)winehq.org

April 24, 2025

Wine staging 10.6 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.6 (333 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * user32: Call UpdateWindow() during DIALOG_CreateIndirect. * Send WM_NCPOINTERUP on focus regain. * cryptext: Implement CryptExtOpenCER. Removed (No longer required). * d3dx9_36-DDS (fixed upstream) Added: * None Updated: * vkd3d-latest * odbc32-fixes Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

April 21, 2025

Upcoming vkd3d 1.16 release

by Henri Verbeet

Hi all, The planned release date for vkd3d 1.16 is May 20. That means the public API will become frozen a week from now on April 22, and features will be frozen two weeks before the release, on May 6. This (of course) does not mean that development should slow down or stop; after making sure that we're in good shape to release, this would be the ideal time to make sure any larger features are ready to get merged at the start of the next development cycle. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify that all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Get any larger features ready to get merged at the start of the next development cycle. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 1.17 is August 21. Regards, Henri

April 15, 2025

Re: Apple Silicon compilation

by robert lippmann

I noticed Alexandre added a commit for 64k page sizes on ARM. Does that mean it’s one step closer? :)

April 10, 2025

Wine staging 10.5 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.5 (336 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * winex11.drv: Add support for _NET_ACTIVE_WINDOW. * user32: Before asking a WM to activate a window make sure that the window is in foreground and not minimized. * shell32: Added stub for IEnumObjects interface. * shell32: Added stub for IObjectCollection interface. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * ntdll-Syscall_Emulation * ntdll-ForceBottomUpAlloc Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

April 6, 2025

Re: Troubleshooting openSUSE's packaging process

by Alexander Leithner

Am 05.04.25 um 14:52 schrieb Alexandre Julliard: > Alexander Leithner <aleithner(a)level101.at> writes: >> Indeed, the build script on OBS exports a bunch of additional flags >> before configuring Wine as seen above, including setting >> -Werror=return-type. >> >> Running configure with CFLAGS='-Werror=return-type ' also is enough to >> reproduce OBS' config.log output locally on my machine. Is this a bug in >> -mabi=ms detection or should OBS not set -Werror=return-type? > > We can work around this specific failure, but yes, setting -Werror > options is a bad idea, particularly during configure. > >> As a side note, OBS also enables Fortify. Isn't this subsequently >> disabled by configure anyway? If so, I imagine OBS could just not enable >> it in the first place, right? > > Yes, it's useless. Thanks for all the help; I've submitted a change request to openSUSE's packaging on OBS. For the time being, exporting -Wno-error=return-type in CFLAGS and CXXFLAGS before configure is called does the trick. Let's see if it'll be accepted. This could be removed if/when the configure test is modified to work in case -Werror=return-type is set. Best, Alexander Leithner

April 5, 2025

Re: Troubleshooting openSUSE's packaging process

by Alexandre Julliard

Alexander Leithner <aleithner(a)level101.at> writes: > Am 04.04.25 um 15:44 schrieb Alexandre Julliard: >> Alexander Leithner <aleithner(a)level101.at> writes: >>> Shouldn't GCC provide support for -mabi=ms out of the box? >> >> Yes, there must be something else going on. Is the config.log file >> available? > > OK, I've managed to extract config.log from a local OBS build. The > section relevant to -mabi=ms reads: > > configure:20674: checking for working -mabi=ms > configure:20693: gcc -m64 -c -O2 -Wall -U_FORTIFY_SOURCE > -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables > -fasynchronous-unwind-tables -fstack-clash-protection > -Werror=return-type -mabi=ms conftest.c >&5 > conftest.c: In function 'a': > conftest.c:165:79: error: control reaches end of non-void function > [-Werror=return-type] > 165 | int a(int b, ...) { __builtin_ms_va_list list; > __builtin_ms_va_start(list,b); } > | > ^ > cc1: some warnings being treated as errors > configure:20693: $? = 1 > > Indeed, the build script on OBS exports a bunch of additional flags > before configuring Wine as seen above, including setting > -Werror=return-type. > > Running configure with CFLAGS='-Werror=return-type ' also is enough to > reproduce OBS' config.log output locally on my machine. Is this a bug in > -mabi=ms detection or should OBS not set -Werror=return-type? We can work around this specific failure, but yes, setting -Werror options is a bad idea, particularly during configure. > As a side note, OBS also enables Fortify. Isn't this subsequently > disabled by configure anyway? If so, I imagine OBS could just not enable > it in the first place, right? Yes, it's useless. -- Alexandre Julliard julliard(a)winehq.org

April 5, 2025