Bug 124387
| Summary: | [ASAN] Ability to disable all ASSERTs except for ASSERT_WITH_SECURITY_IMPLICATION | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | David Farler <dfarler> |
| Component: | Tools / Tests | Assignee: | David Farler <dfarler> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | ap, ayao, ddkilzer, jeffrey+webkit, mrowe |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
David Farler
Since Debug builds are going to be catching assertions anyway and ASAN builds are more geared toward automation, we should at least set ASSERT_DISABLED=1 for the builds in the asan.xcconfig.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
David Farler
It also looks like there is already a convenient ifdef for ADDRESS_SANITIZER which we can use for ASSERT_WITH_SECURITY_IMPLICATION.
David Farler
Hm, looks like ASSERT_DISABLED=1 and ADDRESS_SANITIZER -> ASSERT_WITH_SECURITY_IMPLICATION is an invalid combination because isInAtomicStringTable is wrapped with #if !ASSERT_DISABLED so the build fails with a missing implementation.
David Farler
Ah, I was wrong. ASSERTIONS_DISABLED_DEFAULT =1 is the top level. However, this gets reset to 0 ifndef NDEBUG (i.e. for Debug builds).
There are several categories underneath that are controlled by the top level ASSERTIONS_DISABLED_DEFAULT, so I'll see how I can do with setting those. It looks like those are the only places where ASSERTIONS_DISABLED_DEFAULT is accessed.
David Kilzer (:ddkilzer)
Is the goal to build with ASSERT_DISABLED=1, but with ASSERT_WITH_SECURITY_IMPLICATION enabled? I think that would be a very useful combination.
David Farler
I'm finding out the hard way that no one has recently, if ever, broken the assumption that Debug -> Asserts. There are some mismatches with #ifndef NDEBUG and #if !ASSERT_ that cause build/link failures.
David Kilzer (:ddkilzer)
I think this was fixed by another commit.
Maybe commit r160462 for Bug 125329.
David Farler
Yep. Closing.
*** This bug has been marked as a duplicate of bug 125329 ***