I'd also note that Google at least used to ship a similar kind of thing to their Canary users a few times a week, called SyzygyASAN:
http://blog.chromium.org/2013/05/testing-chromium-syzyasan-lightweight.html I haven't found a ton of detail about whether they still do it but that blog post does say "In the last three weeks, we’ve found 150 new bugs in Chromium, several of which could lead to security vulnerabilities." We already have a couple of extra checks in Nightly, like compartment checking assertions, that have turned up issues we would not have found otherwise. Even a single report can sometimes identify an issue, and allow us to fix it. So I would bet that having more people run builds with even more checking will turn up things to fix. Andrew On Tue, Dec 15, 2015 at 6:36 AM, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > Hi, > > 0/ Context > > As part of the JS engine a lot of issues which are reported on crash-stats > are rarely actionable. I personally waited a few times on equivalent > fuzz-bugs, in hope to fix a crash-stat issue by luck. One of the proposal > we made in Orlando was to investigate if we could improve the reports that > we get from crash-stats. > > Among the idea, was the idea to ship ASan builds to nightly users. > > This email is a summary of the problems which are blocking. I also listed > the persons involved in the discussion, and which might be contacted to > help solving these issues. > > 1/ Would ASan be useful? > > While asking Bob Clary [:bc], he reported that even if he did not measure > the effectiveness of ASan reports, he once noticed that an ASan bug got > marked as a duplicate a of 12 non-ASan crashes. > > As Bob & Decoder mentioned, even if we do not ship ASan builds to users, > we should at least use Windows ASan builds with Bughunter, and fuzzing > automation. > > 2/ Current Blockers: > > 2.1/ Windows Clang ASan builds are not stable yet. > > Apparently we have a few issues opened against clang, and we should push > these forward to make sure that we can have a stable build. Part of the > stability issues might be related to the way our build system is working as > we are linking crt library both statically and dynamically inside Gecko. > > It seems that part of the issue might be related to the fact that Clang > default to cl.exe when Clang fails at compiling, and a guess from Raymond > was that we have ABI issues caused by a miss conversion of the command line > arguments. > > If you are interested to talk more, or help fix clang issues, you should > contact the following persons: > > - Raymond Forbes [:rforbes] > - Nathan Froyd [:froydnj] > - Jeff Muizelaar [:jrmuizel] > - Ehsan Akhgari [:eshan] > > Also, we have few Clang contributors within Mozilla who might have a bit > more knowledge about the persons to ask to get momentum on the clang > issues, such as: > > - Jakob Stoklund Olesen [:jolesen] > - Dan Gohman [:sunfish] > > And for our build system issues on Windows, we should contact: > > - Mike Hommey [:glandium] > > 2.2/ Enable Crash reporter on ASan builds. > > The crash reporter is currently disabled on ASan builds, we need to figure > out why, one hypothesis (I do not recall the author) was that we have > issues with the SEGV handler. > > Another issue, is that the crash reporter does not capture the stderr > stream. Thus we might have to make additional patches to clang to give it > the ability to spew the reports in a file, that we can later attach to the > bug report. > > I don't know who is the right person, but I briefly discuss this issue > with Ted Mielczarek [:ted]. > > 2.4/ Soccoro interface to display multiple backtraces. > > Currently Soccoro only has support to display one backtrace. On the other > hand ASan builds might report 2 / 3 backtraces (allocation site, > deallocation site / crash site). We would have to extend Soccoro interface > to be able to search for the different backtraces, such that we can make > buckets of crashes which have identical allocation sites / deallocation > sites. > > 2.5/ Release Management. > > ASan builds have a x2 overhead, and this implies that we have to ship > different binaries, ASan is not a simple toggle (as far as I know). > > The performance impact is too high to ship ASan builds by default > (Lawrence Mandel). And as this implies that we have to ship a new version > of Firefox, we would have to let people opt-in for a short while on nightly > before making them fallback to the normal nightly, or suggest this ASan > builds on supports.mozilla.org to investigate. > > The person to contact might be Sylvestre Ledru [:Sylvestre], based on > Lawrence suggestion. > > -- > Nicolas B. Pierron > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
