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-ch...
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-ch...
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.6... [7] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-04-05_wine-10.6... [8] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-04-05_wine-10.6... [9] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-04-05_wine-10.6...
On Sat, Apr 26, 2025 at 4:36 PM Bernhard Übelacker bernhardu@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.6...
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-ch...
Am 28.04.25 um 06:44 schrieb Alex Henrie:
On Sat, Apr 26, 2025 at 4:36 PM Bernhard Übelacker bernhardu@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.6...
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-ch...
Hello Alex, thanks for testing and fixing found issues. I missed also in the readme I am using currently a new-style-wow64 configure. Unfortunately I did not get around to put those parts into scripts. However, I rebased to current release and new test runs are in the asan_reports_x86(_64) subdirectories.
https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-04-26_wine-10.7...
Kind regards, Bernhard
Am 06.05.25 um 14:49 schrieb Bernhard Übelacker:
Am 28.04.25 um 06:44 schrieb Alex Henrie:
On Sat, Apr 26, 2025 at 4:36 PM Bernhard Übelacker bernhardu@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.6/README-ASan.md?ref_type=heads
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-checkers
Hello Alex, thanks for testing and fixing found issues. I missed also in the readme I am using currently a new-style-wow64 configure. Unfortunately I did not get around to put those parts into scripts. However, I rebased to current release and new test runs are in the asan_reports_x86(_64) subdirectories.
https://gitlab.winehq.org/bernhardu/wine/-/tree/asan- pe_2025-04-26_wine-10.7?ref_type=heads
Kind regards, Bernhard
Hello, I rebased the current state of the this ASan experiment here [1].
Results of running the conformance tests can be found in [2] [3].
[1] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-05-06_wine-10.8... [2] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-05-06_wine-10.8... [3] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-05-06_wine-10.8...
Kind regards, Bernhard
-
Alex Henrie -
Bernhard Übelacker