New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 714718 link

Starred by 4 users
Status: Assigned
Owner:
█ dshi@chromium.org
Last visit > 30 days ago
Cc:
█ dshi@chromium.org
█ ivanpe@chromium.org
x...@chromium.org
akes...@chromium.org
derat@chromium.org
davidri...@chromium.org
abodenha@chromium.org
█ keta...@chromium.org
r...@chromium.org
vapier@chromium.org
█ jrbarnette@chromium.org
█ josa...@chromium.org
jamescook@chromium.org
sjg@chromium.org
ihf@chromium.org
█ bhthompson@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Track Chrome crash rate in the CQ and PFQ

Project Member Reported by steve...@chromium.org, Apr 24 2017 
Chrome sometimes crashes during tests without causing test failures.

There are several reasons for this:
* Crashes during shutdown after the test has passed.
* Other crashes that do not affect the test results.
* Crashes that are infrequent (and may effect multiple tests) that cause difficult to identify failures and contribute to overall test flakiness.

Currently we do not track the Chrome crash rate in CQ/PFQ tests, nor do we have a straightforward way to examine these crashes.

We have recently been making decisions based on secondary information (e.g. increased network traffic due to crashes).

At minimum we need to identify when and where chrome crashes occur so that we can monitor the crash rate and investigate crashes.

Ideally we should also come up with a maintainable solution for easily tracking chrome crashes so that they can be identified and fixed before they show up in the dev or beta channel crash reporter.

Comment 1 by davidri...@chromium.org, Apr 24 2017

Cc: davidri...@chromium.org
It seems like it would be useful if we can count crashes per test during parsing/log upload, and then combine that up to per suite and finally up to a per build level with data being reported to both Monarch and Cloud Datastore.

Comment 2 by keta...@chromium.org, Apr 24 2017

Cc: derat@chromium.org
+derat

Comment 3 by sjg@chromium.org, Apr 25 2017

Cc: sjg@chromium.org

Comment 4 by akes...@chromium.org, Apr 25 2017

Cc: dshi@chromium.org
Labels: results-cleanup
cc +dshi is working on a ddoc for some cleanup/overhaul of results+crash collection

Comment 5 by aut...@google.com, May 16 2017

Owner: dshi@chromium.org
@dshi - I think this rolls into your planned crash work, please re-assign if that's not accurate

Comment 6 by akes...@chromium.org, Jul 17 2017

Labels: akeshet-pending-downgrade
ChromeOS Infra P1 Bugscrub.

P1 Bugs in this component should be important enough to get weekly status updates.

Is this already fixed?  -> Fixed
Is this no longer relevant? -> Archived or WontFix
Is this not a P1, based on go/chromeos-infra-bug-slo rubric? -> lower priority.
Is this a Feature Request rather than a bug? Type -> Feature
Is this missing important information or scope needed to decide how to proceed? -> Ask question on bug, possibly reassign.
Does this bug have the wrong owner? -> reassign.

Bugs that remain in this state next week will be downgraded to P2.

Comment 7 by akes...@chromium.org, Jul 24 2017

Labels: -akeshet-pending-downgrade Pri-2
ChromeOS Infra P1 Bugscrub.

Issue untouched in a week after previous message. Downgrading to P2.

Comment 8 by cindyb@chromium.org, Jun 8 2018 

Hi, this bug has not been updated recently. Please acknowledge the bug and provide status within two weeks (6/22/2018), or the bug will be archived. Thank you.

Comment 9 by benhenry@chromium.org, Aug 2

Status: Assigned (was: Available)
►

Sign in to add a comment