On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione <kmagli...@mozilla.com> wrote:
> On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote: > >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. > > This would actually potentially even give us better information > than fork-and-crash, since we should be able to include JS > stacks in that setup too. We've never been able to do that in > ordinary crash reports, since breakpad doesn't know how to > unwind JS stacks, and we can't safely ask the JS runtime to do > it while we're crashing. > Though keep in mind that any stack that includes content JS is going to likely count as PII, so it would have to be hidden by default on Soccorro. > >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 > > -- > Kris Maglione > Senior Firefox Add-ons Engineer > Mozilla Corporation > > Common sense is the collection of prejudices acquired by age 18. > --Albert Einstein > > _______________________________________________ > 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