https://bugs.winehq.org/show_bug.cgi?id=40330
--- Comment #9 from Kyle Auble kyle.auble@zoho.com --- (In reply to Austin English from comment #6)
Hi Kyle,
I hadn't tried this in a while, but just did with 7.3.0.
Doing: ./configure CFLAGS="-Og -fsanitize=address" LDFLAGS="-fsanitize=address" make -j $(nproc)
failed. I need to add -lasan -pthread.
After that, fails when it tries to make fonts with output similar to attachment 53999 [details]. I'll attach a patch that avoids it, but it's a hack.
Hey Austin, thanks for testing it hands-on and updating the wiki too.
I'm actually going to be moving on from Wine, but I wanted to keep an eye on the few bugs I've been involved with. Anyways, I don't have any triage permissions so I can't update the bug itself, but it sounds like there are actually two issues:
1. From researching the docs, there are a few linker flags (like "--no-undefined" and "-z,defs") that are conceptually incompatible with ASan. AFAICT though, wine's build configuration doesn't use them. Clang also has some kinks that apparently require you to link in ASan differently, but this report discusses GCC.
Just skimming the actual ASan documentation and bug tracker, they seem pretty adamant that manually calling any flags besides "-fsanitize=address" is deprecated and shouldn't be necessary. There are still lots of people using it though, and it's obviously important here so I'm thinking this deserves a bug-report with ASan. Besides documenting it in our building instructions, I suspect this isn't ultimately Wine's bug.
2. Now as for the sfnt2fon problem, it looks like that actually may just be ASan doing its job. At least their documented example of a heap-overflow at compile-time is also a fatal error: https://github.com/google/sanitizers/wiki/AddressSanitizerExampleHeapOutOfBo...
I definitely don't know the code well enough to say for sure, but unless it's a false positive, for now I would interpret it as a legitimate overflow. You said you got a similar log to the original reporter, but there are gaps in his call-stack trace. Any guesses at if/where sfnt2fon might be acting funny?