So, I don't think we need to do anything fancy with forking - we'd just need to capture stacks and send them via telemetry rather than as a crash report. This was the idea behind bug 1209131, which got pretty far along but never made it to the finish line.
I spoke with Georg about it recently, and got the impression that his team could get it finished if we had a current use-case. Hooking it up to MOZ_ASSERTs on nightly builds seems like a pretty good one. On Wed, Sep 19, 2018 at 5:05 PM Randell Jesup <rjesup.n...@jesup.org> wrote: > >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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
