https://bugs.winehq.org/show_bug.cgi?id=40330
--- Comment #13 from Kyle Auble kyle.auble@zoho.com --- Ah, this bug is a veritable hydra!
I was just thinking some, and I realized that in addition to the sfnt2fon and memory conflicts, the Wine preloader is linked statically. Is that possibly causing any problems, or are ASan and Wine's configure smart enough to ignore the "fsanitize" flag when building the preloader?
(In reply to Austin English from comment #11)
Short answer is https://source.winehq.org/git/wine.git/blob/HEAD:/tools/sfnt2fon/sfnt2fon. c#l577
I wasn't sure how accurate the line-numbers for ASan were, but that's nice that it lands close to the actual problem.
(In reply to Austin English from comment #12)
Though after getting it to build, running wine fails; looks like the preloader interferes with ASAN: ==9822==Shadow memory range interleaves with an existing memory mapping.
...
I tried the LD_PRELOAD workaround: export ASAN_OPTIONS=halt_on_error=0 export LD_PRELOAD="/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/libasan.so.4 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/32/libasan.so.4"
as well as -fsanitize-recover=address, but none of those helped. From a quick glance at ASAN bugs, sounds like it's a WONTFIX.
I guess this is the real essence of the bug; maybe we should note the runtime conflict with the preloader in the title? You're probably right that working around the preloader would probably qualify as WONTFIX for the ASan team.
However, setting aside practicality for a second and looking at it as "do the right thing," couldn't the Wine preloader and ASan theoretically respect each other? Doesn't Wine need the preloader to reserve specific memory addresses whereas ASan only needs to preemptively reserve some range for shadow memory? Or am I completely misunderstanding?