Closed Bug 1230978 Opened 9 years ago Closed 7 years ago

Very frequent e10s tsvg TalosError: TIMEOUT: TART

Categories

(Testing :: Talos, defect)

Product:
Testing
Component:
Talos
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(e10s+, firefox45 affected, firefox46 fixed)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
e10s + ---
firefox45 --- affected
firefox46 --- fixed

People

(Reporter: philor, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure)

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: 8 years ago
Resolution: --- → FIXED
Thanks Mark!
status-firefox46: --- → fixed
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)
no instances in the last 2 months.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.