On Thu, Sep 22, 2016 at 6:07 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On 2016-09-22 9:07 AM, Gijs Kruitbosch wrote: > > On 22/09/2016 05:28, Nicholas Nethercote wrote: > >> Greetings, > >> > >> Assertions, such as MOZ_ASSERT, are great. But they only run in debug > >> builds. > >> > >> Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds. > >> > >> I want to highlight a nice case where converting a normal assertion > >> into a release assertion was a win. In bug 1159244 Michael Layzell did > >> this in nsTArray::ElementAt(), to implement a form of always-on array > >> bounds checking. See > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for > >> discussion of how this is finding real bugs in the wild. (As well as > >> identifying new bugs, it's also helping understand existing crash > >> reports, e.g. see bug 1291082 where the crash signature changed.) > >> > >> Obviously we can't convert every normal assertion in the codebase into > >> a release assertion. But it might be worth thinking about which normal > >> assertions are good candidates for conversion. Good candidates include > >> any assertion where the consequence of failure is dangerous, e.g. > >> might cause memory access violations. > >> > >> Nick > > > > Yes please. This + diagnostic assert also helps frontend people who > > build and run opt builds (because debug builds are too slow to be > > usable, especially when combined with the browser toolbox (JS > > debugging)). Right now I miss some of these and then only find out when > > the tests that I did run go orange on try and/or inbound/autoland, and > > then I have to locally change the relevant C++ so I can test in my opt > > build (or resign myself to doing a separate clobber debug build > somewhere). > > What exact debug configuration is too slow for you? People who want to > debug C++ generally turn optimizations off, but for front-end devs, I > think building with --enable-debug and --enable-optimize should give you > an optimized build with the debug facilities turned on, which should be > much faster. Although it is not going to be as fast as a > --disable-debug --enable-optimize build, there's a lot of value in > Mozilla developers running builds with debug checks turned on, so that > we can get good bug reports when an assertion fires when working on a > front-end feature, etc. > I used to do that in the past, but nowadays artifact builds have changed the cost-benefit trade-off so very few people bother AFAIK, when not touching C++ code. If we could get artifact builds to use --enable-debug and --enable-optimize (or have an option to do so) that could change the calculus. Panos _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
