Closed Bug 1365123 Opened 7 years ago Closed 7 years ago

Large regression in main + content crashes on trunk around March 7 from ~11 to 20

Categories

(Core :: DOM: Content Processes, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID
Performance Impact none
Tracking Status
firefox55 - fix-optional
firefox56 --- affected

People

(Reporter: kbrosnan, Unassigned)

Details

(Whiteboard: [pi-monitoring])

* Visit https://telemetry.mozilla.org/crashes/
* click on the M+C cell for Nightly
* notice that the crash rate for nightly has been increasing since March 7th 2017

March 6th was the first day of development for v55.
The large regression is from around March 7th where the M+C crash rate goes from ~11 to ~20
Summary: Large regression in main + content crashes on trunk → Large regression in main + content crashes on trunk around March 7 from ~11 to 20
i was under the impression that M+C-S should be used as the indicator for stability - that rate was also on the rise after march 7 but it's now mostly back at the level seen before that.
so the sustained increase was mostly coming from content shutdownkill crashes that are mostly discarded as they may not even be noticeable for users (maybe due to e10s-multi there are more opportunities for shutdownkills/hangs of content processes?).

i don't see any earth-shattering signature shifts between 54.0a1 & 55.0a1 either:
https://mozilla.github.io/stab-crashes/scomp.html?limit=50&common=product%3DFirefox%26release_channel%3Dnightly%26date%3D%3E2017-01-01&p1=version%3D54.0a1&p2=version%3D55.0a1
Doubling the number of shutdown crashes seems like a bad regression to me. Needs an owner to either accept the increase in shutdown crashes or investigate the cause.
I don't see this being a performance bug to fix under Quantum Flow. If it is please help me understand the situation.
Flags: needinfo?(kbrosnan)
Whiteboard: [qf] → [qf-]
[Tracking Requested - why for this release]: doubled to tripled the shutdown crash rate in Fx 55
Flags: needinfo?(kbrosnan)
bsmedberg, do you know who could investigate this big increase in shutdown crashes?
Flags: needinfo?(benjamin)
Tracking 55+ for this regression.
I expect that this is "just" us increasing the # of content processes. The chances that a particular content process have a hang don't appear to have changed, we've just introduced more of them.

One of the reasons we are using M+C-S as our metric is precisely because this scales with e10s and we have no plan currently to do much about this. So I would suggest WONTFIXing this, but that is probably not my call but a product-level call with Jeff.

Kevin can you add this topic to an e10s meeting agenda or set up a call with you/me/Jeff/elan to confirm?
Component: General → DOM: Content Processes
Flags: needinfo?(benjamin) → needinfo?(kbrosnan)
Talked with Elan this will be on the Friday E10S meeting round table.
Flags: needinfo?(kbrosnan)
Decision is that this is not a release blocker for e10s multi. Elan put it in the e10s backlog.
Whiteboard: [qf-] → [qf-][monitoring]
I don't feel the need to track this bug for 55. I am not sure if there is anything actionable or uplift-able to Beta in this specific bug.
Whiteboard: [qf-][monitoring] → [qf-][pi-monitoring]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Performance Impact: --- → -
Whiteboard: [qf-][pi-monitoring] → [pi-monitoring]
You need to log in before you can comment on or make changes to this bug.