Flag origin trial usage in crash reports |
|||
Issue descriptionThrough Finch we can do partial rollouts to measure changes in crash rates and other metrics. Since by design Origin Trial usage is a small percentage of users doing an A/B test would further reduce the size of the population and also frustrate developers because their tokens would only work on a fraction of the population. This issue tracks adding a flag to crash reports indicating which origin trials have been activated during the browser session in which the crash occurred. A concrete example of this is for the Shape Detection Origin Trial we would like to be able to measure GPU process crash rates in order to determine if use of this feature has a negative effect on browser stability. Looking for Shape Detection functions in crash stacks are not enough because instability may compound from one call to another.
,
Sep 11
Also cc-ing some OT folks for suggestions.
,
Sep 11
I suspect that this would have to be limited to renderer crashes, as any OT-related code in the browser is always enabled, just in case a renderer needs it. Or would we want to implement a flag in the browser that indicates that some live renderer has an active trial token?
,
Sep 11
Yes I think only the renderer crashes are relevant. So I suspect any frame in a renderer process which runs and OT will flag the whole process as such? I am not sure if it will be a great help to low-process-count platforms such as Android.
,
Sep 11
I don't think synthetic trials make sense since they are still browser-wide. For original trials you only want to mark the renderers affected, so I think you'd need a custom mechanism. +rsesek who can advise on best way to add data to crash uploads nowadays
,
Sep 11
I very much want to flag the entire browser with the OTs that have been activated in any renderer. My first use case for this is detecting GPU process instability.
,
Sep 11
Reilly -- trials that have been activated at *any* point since browser startup, or just trials which are currently active in some renderer? (or both?)
,
Sep 11
Trials that have been activated in any renderer at any point since browser startup.
,
Sep 11
asvitkine@: Given comment #8 should introducing "a" synthetic trial for all OTs suffice (or maybe I am missing something here). I remember we used synthetic trials for a similar purpose when running a finch trial for OOPIf-based GuestViews.
,
Sep 11
Given that trials come and go, and there may be two or more stability-affecting trials active at the same time, we might need to track them separately, in a bitfield in the browser, and then actually report them as as set of strings to the crash uploader.
,
Sep 11
Yes, in general I agree it does sound better to have a (separate?) pathway for OT and make it future-proof as well (by including all OTs, and more).
,
Sep 11
https://cs.chromium.org/chromium/src/components/crash/core/common/crash_key.h is the way to get data uploaded with a crash report. |
|||
►
Sign in to add a comment |
|||
Comment 1 by ekaramad@chromium.org
, Sep 11Status: Available (was: Untriaged)