[Bug 40330] Build fails with AddressSanitizer.

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=40330

--- Comment #9 from Kyle Auble <kyle.auble at 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/AddressSanitizerExampleHeapOutOfBounds

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?

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.