1478096, 1494052, 1503225, 1557095, 1403548, 1426176, 1465545, 1476080, 1476098, 1477037, 1477212, 1477434, 1477490, 1477981, 1478312, 1478591, 1486400, 1492508, 1493050, 1494021, 1520801
1477057, 1478331, 1479399, 1480044, 1484655, 1554600, 1386304, 1413696, 1415689, 1419371, 1422269, 1471532, 1471647, 1473259, 1478143, 1479385
This bug should serve as a tracking bug for all bugs related to the AddressSanitizer (ASan) Nightly Project. The goal of the project is to provide a version of Nightly that is built with ASan and automatically reports back any ASan crash information to us. The project will be opt-in and targeting users that are willing to run these kinds of builds for daily browsing despite the performance overhead that comes with ASan. Since ASan detects memory corruptions much better (e.g. triggers on use-after-free, which often does not crash) and also provides much better diagnostic information, the results might allow us to fix additional stability and security bugs in our codebase. In terms of operating systems, the first OS to be supported will be Linux, maybe we can extend this to Mac later. ASan for Firefox on Windows is in its early stages so it is not clear when it will be stable enough.
This could be a problem for sandboxing: currently we disable sandboxing on Linux ASan builds, because of problems with LeakSanitizer (see bug 1287971 comment #9), and to a certain extent we rely on Nightly users to catch problems on unusual configurations or distributions that Mozilla's test infrastructure doesn't cover. So if the more experimental parts of the Linux Nightly population start using ASan builds, this would increase our risk of brokenness making it to Release. It sounds like this ASan Nightly won't need Leak Sanitizer, which suggests a possibility: get sandboxing + ASan working again, have it disable LSan in child processes by default, and allow tests to choose LSan instead of sandboxing. The one weak point there is getting test coverage for ASan + sandboxing, but as long as ASan and sandboxing are tested separately, the risks are mainly around the ASan crash handler working as expected in child processes (including media plugins if possible), and that should be testable much more cheaply than running an extra copy of the entire test suite.
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #1) I don't think this is an issue at the moment, because we don't expect that a substantial amount of the Nightly population will participate in this program. This program is entirely opt-in and requires a separate build to be downloaded. It is not that we move a percentage of Nightly users to this type of channel. That said, if you can get sandboxing to work properly with ASan (and the ASan reporter system addon), that would of course be nice :)
Summary: AddressSanitizer Nightly Project → [meta] AddressSanitizer Nightly Project
You need to log in before you can comment on or make changes to this bug.