+khushal who moved code around a bit there.

It might be that a signature changed. Or his changes might have improved some recovery.

Ya, I was wondering about a signature change but don't see a corresponding shift on the browser breakdown. content::NavigationControllerImpl::RendererDidNavigateAutoSubframe (the one big increase) isn't a browser crash - it's a "dump without logging"

Also looking at GPU:
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Android%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27gpu-process%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&compProp=product.Version&v1=51.0.2704.81&v2=52.0.2743.98

what on earth happened to "gpu hang"?

Ummm, the code might not be retrying in case of gpu process initialization failure, https://cs.chromium.org/chromium/src/content/browser/renderer_host/context_provider_factory_impl_android.cc?sq=package:chromium&l=240

I'll send a patch to fix that.

Spitzer A/B experiments showed a 30% browser stability improvement:

https://uma.googleplex.com/p/chrome/variations/?sid=1f82c17678269c006e23ac967cbbf6da

(dates after 8/9 are not usable since we bumped control to zero and spitzer to 100%).

When I was looking at the actual crash data and limited by experiments there were appreciable differences in the number of reported crashes. 

Oh this is stable. Sorry I got confused between the dev regression and stable improvement.

khushal, not your patch if stable right?

Nope. That patch landed last week.

yfriedman@ were you going to investigate this anymore? All the sources I've looked at confirm this is legit. We did expect improvements here, the shocking points are (1) how much browser stability improved and (2) that GPU/renderer effectively remains the same (early data suggested minor regressions).

-> yfriendman per previous comment. Otherwise we can close.

I'll investigate a bit next week as I'm stability sheriffing. If everything looks legit then I'll close this.

Yaron is out for now.

Possibly issue 604295 being fixed, so it went from 7% -> 0%, though DidFailToInitializeOutputSurface went from 17% -> 4%, OnMessageReceived went from 0 -> 3% and RendererDidNavigateAutoSubframe went from 0 -> 12%, so net change is only 24% -> 19%, a 5% difference.

This does not account for browser crash rates going from 230 CPM to 150 CPM, a 35% drop. :/

Nothing else looks significant at least from the crash frontend: https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Android%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&compProp=product.Version&v1=51.0.2704.81&v2=52.0.2743.98

@wnwen: See c#4. It's pretty clear this is directly related to the launch of Spitzer due to A/B tests. I don't think issue 604295 has any relation. While larger than expected, we did expect browser process stability to improve.

@c#2 - GPU hang seems to have been split up into the long tail rather than a blanket 15% bucket at the top.

@c#11 - Agreed, the percentage drop also roughly matches. Good work on Spitzer. :)

Will close the bug as we've identified Spitzer going 100% on stable being the root cause.