There's also MOZ_DIAGNOSTIC_ASSERT, which is fatal in pre-release builds but not release ones. It can be a good compromise to find bugs in the wild when the performance cost is probably negligible but you're still not quite comfortable shipping it on release. I added it last year while working on stability for the media stack, and found it very useful.
bholley On Wed, Sep 21, 2016 at 9:28 PM, Nicholas Nethercote <n.netherc...@gmail.com > 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 > _______________________________________________ > 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
