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.
dev-platform mailing list

Reply via email to