On Wed, Sep 19, 2018 at 8:38 PM Bobby Holley <bobbyhol...@gmail.com> wrote:
> 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. > That would indeed be wonderful to have! > 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 > -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
