1250716 - Compare crash submission rates for e10s vs. non-e10s

Status: RESOLVED FIXED

(Toolkit :: Telemetry, defect, P4)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

When comparing how often a particular signature occurs in e10s and non-e10s, it would be nice to know if content process crashes are submitted more or less often than main process crashes. The UI is different and it wouldn't be surprising if the rates are different. Can we do a telemetry analysis of this using the data from the 45 beta no-addon experiment? poiru, is this something you could do?

Comment 1

[Biru [:poiru]]

(In reply to Bill McCloskey (:billm) from comment #0)
> When comparing how often a particular signature occurs in e10s and non-e10s,
> it would be nice to know if content process crashes are submitted more or
> less often than main process crashes. The UI is different and it wouldn't be
> surprising if the rates are different. Can we do a telemetry analysis of
> this using the data from the 45 beta no-addon experiment? poiru, is this
> something you could do?

How do we track the submission rate?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Hm, I thought we had Telemetry probes for this, but looking at Histograms.json, I don't see any good candidates...

ted, do you know if we have any way of knowing how many times the main-process crash reporter dialog is shown, but a crash report is _not_ sent? Glancing at the client code, I don't see us recording that anywhere, but I wanted to be sure...

Comment 3

[Benjamin Smedberg]

We know from monitoring that content process crashes are submitted at a rate of about 10%. Main-process crashes are submitted at a rate of 50-60%

PROCESS_CRASH_SUBMIT_ATTEMPT records attempts for "main", "content", and "plugin" so you can compare that with the crash rate to generate a submission rate.

Comment 4

[(not currently active) Ted Mielczarek]

Yeah, I don't know the telemetry bits well, bsmedberg or gfritzsche are better people to ask.

Comment 5

[Biru [:poiru]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #3)
> PROCESS_CRASH_SUBMIT_ATTEMPT records attempts for "main", "content", and
> "plugin" so you can compare that with the crash rate to generate a
> submission rate.

I added this to the stability analysis: https://gist.github.com/poiru/e7b9b89282179b17125f

                                      non-e10s       e10s
usage hours                               5419       4774
chrome crashes                           73078      33801
content crashes                          11797      76223
plugin crashes                           42173      56263
main crash rate                          13.49       7.08
main+content crash rate                  15.66      23.04
plugin crash rate                         7.78      11.78
submit attempts per main crash            0.19       0.17
submit attempts per content crash         0.00       0.12

The numbers are <1 so it seems like we don't record PROCESS_CRASH_SUBMIT_ATTEMPT for all crashes (or we're somehow overcounting crashes).

Comment 6

[Benjamin Smedberg]

    "payload/keyedHistograms/PROCESS_CRASH_SUBMIT_ATTEMPT/main-crash",
    "payload/keyedHistograms/PROCESS_CRASH_SUBMIT_ATTEMPT/content-crash"])

These are incorrect. It should be "main" and "content". I'm surprised/concerned that you're getting results for the other two keys.

Comment 7

[Biru [:poiru]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> These are incorrect. It should be "main" and "content". I'm
> surprised/concerned that you're getting results for the other two keys.

I tried "main" and "content" first and was surprised to see that they didn't work. It turns out the keys are represented as PROCESS_TYPE-CRASH_TYPE: https://dxr.mozilla.org/mozilla-central/rev/4ea7408b3eef059aa248f4b00328f8fdb4475112/toolkit/components/crashes/CrashManager.jsm#1081

Comment 8

[Benjamin Smedberg]

You're right, the user story from the original bug was wrong.
Those submission rates for main crashes are low-seeming (on both sides). I wonder why that is. I'd expect something close to 40-50% instead of 20%.

Comment 9

[Benjamin Smedberg]

We know there's a difference, we're comfortable living with the difference.