>On Thu, Sep 20, 2018 at 09:22:12AM +1000, Cameron McCormack wrote: >> On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote: >> > While it may be the case that we may need to be more stable for >> > MOZ_RELEASE_ASSERTs, I very much doubt that every single MOZ_ASSERT in our >> > codebase is actually a guaranteed to never fail, so promoting them all to >> > be enabled in something like Nightly is extremely dangerous in terms of the >> > stability of Nightly for users who are trying to use the browser to get >> > their normal work done. >> >> If it's truly useful to know whether Nightly users are failing these >> MOZ_ASSERT assertions, we could use Telemetry to report their failure >> instead of crashing.> >> (I wonder if we could collect all the same data, and use the same crash >> reporting infrastructure, for non-crashing crash reports like this.) > >On Linux and Mac, we could make MOZ_ASSERT fork and crash in the child, >and continue in the parent process.
Oooh, tricky. (though threads aren't preserved in forks, but the current thread's stack is, so if we care about all threads, we might need to grab pointers to their stacks/etc and store pointers to the stacks before fork()). But even without that it would be good. And yes, we don't have to have it crash the browser (though if it later crashes we'd want to know about assertions we'd hit). Telemetry isn't quite appropriate for reporting it; it could however save a crash report at ASSERT(), then (probably) disable MOZ_ASSERT reports and let the browser continue (and it may well now really crash). This disabling would avoid the cascade effect, but still get us crashreports. This would be a bunch(?) of work in crashreporter - ted? It might be easy invoke a crashreport sampling, and continue, but I suspect it's not, and might be quite hard. -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
