Closed Bug 590415 Opened 14 years ago Closed 7 years ago

Intermittent failure in layout/reftests/bugs/368020-1.html | image comparison (==)


(Core :: Graphics: ImageLib, defect, P3)

7 Branch
Windows XP





(Reporter: philor, Unassigned)



(Keywords: intermittent-failure, regression, Whiteboard: [test disabled])


(1 obsolete file)

Attached file reftest log (obsolete) —
WINNT 5.2 mozilla-central debug test reftest on 2010/08/23 16:10:29
s: win32-slave07

REFTEST TEST-UNEXPECTED-FAIL | file:///e:/builds/moz2_slave/mozilla-central-win32-debug-unittest-reftest/build/reftest/tests/layout/reftests/bugs/368020-1.html |
REFTEST number of differing pixels: 32996

The log is unexciting, since it's just "the background image is totally missing," other than the excitement of that sounding a whole lot like bug 590410, which I just filed.
It is possible for this bug to have been caused by enabling image discarding.  I'll test a patch on the try server which disables image discarding, and will see if this bug happens with image discarding disabled.
Try run for edbc7c5ea1c6 is complete.
Detailed breakdown of the results available here:
    success: 5
    warnings: 1
Total buildrequests: 6
Builds available at
Summary: Intermittent failure in layout/reftests/bugs/368020-1.html → Intermittent failure in layout/reftests/bugs/368020-1.html | image comparison (==)
OK, the try server job I pushed in comment 122 definitely shows that this bug is caused by image discarding being turned on.

He also told me that jlebar has recently done something which could be responsible for the increase in the frequency of this orange.

Do any of you guys have any idea how we can proceed with diagnosing/fixing this bug?  (Note that it only seems to be happening on WinXP)
Blocks: 563088
Component: Layout → ImageLib
Keywords: regression
QA Contact: layout → imagelib
OS: Windows Server 2003 → Windows XP
Images are discarded after 10-20s, rather than 120-240s, due to bug 664290.  If this only happens when image discarding is off, I'd normally suspect that change would have affected this orange's frequency.

But that change landed on m-c on 2011-06-22, and this test seems to have gone crazy starting on 2011-07-21.  That corresponds to bug 666352 and bug 672578.  My guess is 666352 would matter more here.

I'll have a look at what this test is doing...
The difference is in the rightmost border in the testcase.  In img 1 (the reference?), the pixel at the bottom left of each dot in the RHS border has value (225, 225, 0), but in the bad image, the pixel has value (226, 226, 0).

Since this happens so frequently, let's figure out whether either of these two bugs is causing the issue by backing each one out individually and running a bunch of tests, as you did in comment 122.
Parent: comment 185.

I observed the failure with both candidate bugs backed out [1], so I suspect that neither bug 666352 nor bug 672578 has to do with this failure.

I did not observe the failure with bug 666352 backed out and bug 672578 left in [2], which is strange.  But maybe I just got lucky.  I'll kick some more tests to be sure.

Assignee: nobody → netzen
Parent: comment 196.

I haven't seen this failure on try after 17 runs with bug 666352 backed out and bug 672578 left in.

I don't know what to make of this.  Both bugs backed out yields the failure, but when I back out just one, it stops failing?  That's weird...