Spike in failures on linux/win ccov
Categories
(Firefox Build System :: Task Configuration, defect)
Tracking
(firefox-esr140 unaffected, firefox148 unaffected, firefox149 wontfix, firefox150 wontfix, firefox151 fixed)
| Tracking | Status | |
|---|---|---|
| firefox-esr140 | --- | unaffected |
| firefox148 | --- | unaffected |
| firefox149 | --- | wontfix |
| firefox150 | --- | wontfix |
| firefox151 | --- | fixed |
People
(Reporter: amarc, Assigned: jcristau)
References
(Regression)
Details
(Keywords: intermittent-failure, intermittent-testcase, regression)
Since this push from central, many jobs on linux/win ccov have started frequently failing, most of them are confirm failure jobs
Some examples: https://treeherder.mozilla.org/logviewer?job_id=549883508&repo=mozilla-central&task=WgXEQtpTS7uXgvrVI6Wx5A.0
https://treeherder.mozilla.org/logviewer?job_id=549883639&repo=mozilla-central&task=EBxMd4cpRzSo_SBU6UjxEg.0
https://treeherder.mozilla.org/logviewer?job_id=549924732&repo=mozilla-central&task=SetfD97-SwCEPkyCqIfOLQ.0
hi Aryx, do you know what's going on here?
hi Andrew, could these be caused by some kind of worker issue?
Updated•7 months ago
|
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Comment 12•7 months ago
|
||
The linux failures are on g-w cloud linux d2g hosts running the in-tree docker image gw-fxci-gcp-l1-2404-amd64-headless-googlecompute-2026-01-14.
Relops doesn't maintain the in-tree docker images. CC'ing :jcristau, who has been working on them a bit.
| Comment hidden (Intermittent Failures Robot) |
| Assignee | ||
Comment 14•7 months ago
|
||
Are there specific failing tests (for each platform)? The linux worker image hasn't changed since mid-January.
Comment 15•7 months ago
|
||
The count of browser-chrome failures on Linux CCov per push jumped and the tests listed in the duplicate bugs fail either frequently or permanently, e.g. High frequency ccov browser/base/content/test/tabcrashed/browser_aboutRestartRequired_buildid_false-positive.js | single tracking bug (bug 2018417).
Bug 2018418 failed - during the setup function of the test - before only (?) on Try pushes by :gsvelto (example) but no change by Gabriele is part of the changelog.
Gabriele, do you know what started these failures?
| Comment hidden (Intermittent Failures Robot) |
Comment 17•7 months ago
|
||
I suspect it must have been because of a change in how these tasks are selected when running on try. I've got some pre-saved queries that I invoke with ./mach try fuzzy --preset <name> and they didn't include ccov tests, but didn't exclude them either. Recently the ccov tests are always running so I've been tweaking my queries to disable them explicitly unless I need them.
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Updated•7 months ago
|
Comment 32•7 months ago
|
||
I used the git revs to actually get a complete diff for all the changes of this merge to mozilla-central:
https://github.com/mozilla-firefox/firefox/compare/4a30b4e343d1..bfa2c2f2cb7c
My suspicion is that bug 2016051 actually caused this problem given that it touches quite a lot for CCOV builds and we only see these failures for CCOV builds.
Marco, can you please take a look?
Comment 33•7 months ago
|
||
Bug 2016051 is adding a task at the end of all others, so it can't affect what previous tasks in the graph are doing.
The only regression it might have caused is how frequently we run the ccov tasks (see for example bug 2020718), but it can't affect the rate of failures.
Comment 34•7 months ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #33)
The only regression it might have caused is how frequently we run the ccov tasks (see for example bug 2020718), but it can't affect the rate of failures.
What does frequent here mean? We did not run those jobs at all before, so what actually calculates the frequency?
Comment 35•7 months ago
|
||
Note that especially the W-async-cf task (duped bug 2021821) is set to only run on try but not on any trunk branches. So as I read this is related to the frequency when the test is getting run, which jumped from never to always. And it's not related to the number of failures in such tasks - which are mostly expected due to underlying platform issues that need to get fixed.
Comment 36•7 months ago
|
||
OK, I thought the bug was about a higher rate of failures of a task that was already being scheduled in the past. The solution to bug 2020718 would probably fix this too then.
Comment 37•7 months ago
|
||
Set release status flags based on info from the regressing bug 2016051
| Comment hidden (Intermittent Failures Robot) |
Comment 39•7 months ago
|
||
Marco, do you think it might make sense to backout the regressor temporarily until the underlying taskgraph fix has landed and a new release it out? Or isn't it possible due to some other automation / tools depending on this jobs now?
Comment 40•7 months ago
|
||
Unfortunately we can't because we already switched other automation to rely on that.
Comment 41•7 months ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #40)
Unfortunately we can't because we already switched other automation to rely on that.
I thought so. Thanks for confirming. Let’s at least needinfo Andrew so he’s aware of this bug, as his taskgraph update work would likely help here significantly. Hopefully that can move forward quickly.
Comment 42•7 months ago
|
||
Thanks, are you talking about https://github.com/taskcluster/taskgraph/pull/917 ? I'll try and get it ready for review
Comment 43•7 months ago
|
||
(In reply to Andrew Halberstadt [:ahal] from comment #42)
Thanks, are you talking about https://github.com/taskcluster/taskgraph/pull/917 ? I'll try and get it ready for review
Thank you! Yes, that's at least what Marco was pointing at, which should as well help for this bug (see comment 33).
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Comment 59•6 months ago
|
||
Set release status flags based on info from the regressing bug 2016051
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Comment 69•6 months ago
|
||
Amazing. Thanks a lot jcristau!
And yes, the number of jobs for CCOV builds drastically reduced:
I assume that with this change we still run all those jobs that we actually should run.
Marco, maybe you have the overview and could take a look?
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Description
•