+1 on MOZ_DIAGNOSTIC_ASSERT - its been very useful to me as well.
On Thu, Sep 22, 2016 at 6:40 AM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> 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.
> On Wed, Sep 21, 2016 at 9:28 PM, 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
> > _______________________________________________
> > dev-platform mailing list
> > firstname.lastname@example.org
> > https://lists.mozilla.org/listinfo/dev-platform
> dev-platform mailing list
dev-platform mailing list