Very frequent e10s tsvg TalosError: TIMEOUT: TART

RESOLVED WORKSFORME

Status

defect
RESOLVED WORKSFORME
4 years ago
2 years ago

People

(Reporter: philor, Unassigned)

Tracking

(Blocks 1 bug, {intermittent-failure})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+, firefox45 affected, firefox46 fixed)

Details

Blocks: e10s-tests
tracking-e10s: --- → +
Mark is working the issue in bug 1052467.  Just assigning here since this is the bug that shows up in brasstacks.
Assignee: nobody → standard8
Status: NEW → ASSIGNED
Bug 1239963 just landed a fix for this into fx-team.

I think there's still follow-up work that it'd be good if someone did - see bug 1052467 comment 332.
Depends on: 1239963
Whiteboard: [hopefully fixed by bug 1239963]
Nothing since bug 1239963 landed so far. So given our results with try, I'm going to call this fixed.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Thanks Mark!
Whiteboard: [hopefully fixed by bug 1239963]
(In reply to OrangeFactor Robot from comment #21)
> 20 automation job failures were associated with this bug yesterday.

20 new failures almost all on inbound.. all assigned to a closed bug? We haven't touched the code that originally caused this, I think this new set really wants a new bug and investigation, as it obviously started yesterday...
Flags: needinfo?(philringnalda)
Flags: needinfo?(cbook)
as a note, this showed up in the black hole of a broken build, I have pushed to try with 11 changesets to bisect *most* of the revisions in the black hole:
https://treeherder.mozilla.org/#/jobs?repo=try&author=jmaher@mozilla.com&fromchange=680f9797cd4e

As a developer who has rights to commit to mozilla-central, not pushing to try or even doing |mach build| on a patch prior to landing is ending up wasting a LOT of time and resources given the amount of try pushes I have had to do.
tracked this down to:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cc9bef95c7e139056d59851caaa0ca748f416766
Bug 1240169 - Revert to returning a dynamic newtab URL for BROWSER_NEW_TAB_URL r=mconley

asked :oyiptong to look into this in bug 1240169!
Flags: needinfo?(philringnalda)
Flags: needinfo?(cbook)
Ok, if we're treating this as an open bug for test failures, even though its closed and actually a different bug that's causing the issue this time, then sorry, but I'm not going to be assigned/watching it.
Assignee: standard8 → nobody
It'll be fine, after all, we won't just leave that fresh bustage in the tree, we'll only misstar it for a day or two, over the weekend...
Status: RESOLVED → REOPENED
Depends on: 1246695
Resolution: FIXED → ---
Joel, it looks like this has become a frequent intermittent again within the last day or so.  Any idea what happened?
Flags: needinfo?(jmaher)
I see this- doing a lot of retriggers- this could be related to the mesa driver upgrade.
Flags: needinfo?(jmaher)
Depends on: 1253321
no instances in the last 2 months.
Status: REOPENED → RESOLVED
Closed: 4 years ago2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.