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

Reply via email to