Closed Bug 1084118 Opened 11 years ago Closed 11 years ago

Windows XP Intermittent component-alpha-exit-1.html | image comparison (==), max difference: 255, number of differing pixels: 251

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
34 Branch
Platform:
All
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla36
Tracking Flags:
Tracking Status
firefox34 --- unaffected
firefox35 --- unaffected
firefox36 --- fixed
firefox-esr31 --- unaffected

People

(Reporter: KWierso, Assigned: nical)

References

Details

(Keywords: intermittent-failure)

https://treeherder.mozilla.org/ui/logviewer.html#?job_id=3066432&repo=mozilla-inbound builder Windows XP 32-bit mozilla-inbound debug test reftest buildid 20141016111631 builduid dbcf95c374cb48f6955a7fb3698f9efa results warnings (1) revision f5b05c63480d slave t-xp32-ix-101 starttime Thu Oct 16 2014 13:25:27 GMT-0700 (Pacific Standard Time)
I find it a bit curious that this started on mozilla-inbound 3 days ago and hasn't yet appeared on any other trees.
Summary: Intermittent component-alpha-exit-1.html | image comparison (==), max difference: 255, number of differing pixels: 251 → Windows XP Intermittent component-alpha-exit-1.html | image comparison (==), max difference: 255, number of differing pixels: 251
And retriggers on the Windows XP opt reftest on https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=d16adf321576 confirm that it's nical's push.
The only answer I have for "what's different about WinXP reftests on mozilla-inbound than WinXP reftests on every other trunk tree?" is that on m-i we use build slaves in a jacuzzi, a relatively small pool of slaves that only do that one job, to massively increase the chances of getting a dep build. b-i doesn't do WinXP tests, fx-team got clobbered by accidentally switching build harnesses, and mozilla-central is prone to clobbers (by way of just not having an objdir around) because it uses the whole slave pool but builds rarely so they get removed to clear space and they get removed because they are too old. So while I wouldn't count on it, one possibility is that we won't see it again on builds which started after I clobbered Windows on m-i at 09:45.
So much for my clobber theory, since that was on a forced-clobber build which started at 12:33
Actually, the reason this hasn't shown up on a tree other than inbound yet is that it originally landed in: https://hg.mozilla.org/integration/mozilla-inbound/rev/d16adf321576 (bug 1077301 comment 41) and was then backed out for B2G bustage in: https://hg.mozilla.org/integration/mozilla-inbound/rev/fe2216810527 (bug 1077301 comment 42) Then it relanded on inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/197317c196cf (bug 1077301 comment 43) and that relanding hasn't yet been merged to central. So I shouldn't have expected it to be on any other trees, but it will be pretty soon.
I'll look into that before I reland bug 1077301
Flags: needinfo?(nical.bugzilla)
Looks like bug 1077301 spiked this again...
Flags: needinfo?(nical.bugzilla)
I backed it out again. Please verify that WinXP has green reftests on Try (with retriggers) before pushing again.
Assignee: nobody → nical.bugzilla
Status: NEW → RESOLVED
Closed: 11 years ago
status-firefox34: --- → unaffected
status-firefox35: --- → unaffected
status-firefox36: --- → fixed
status-firefox-esr31: --- → unaffected
Flags: needinfo?(nical.bugzilla)
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.