Closed Bug 432954 Opened 12 years ago Closed 12 years ago

qm-xserve06 fails loading reftest 413292-1.html

Categories

(Core :: Web Painting, defect, P1, blocker)

PowerPC
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: dholbert, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

Per bug 432858 comment 9, the newly-added qm-xserve06 tinderbox has failed loading the reftest 413292-1.html, on every build since its first green cycle. (no other systems have had this failure)

REFTEST UNEXPECTED FAIL (LOADING):
file:///builds/slave/trunk_osx_6/mozilla/layout/reftests/bugs/413292-1.html

Sample log: 
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1210304340.1210307191.17948.gz
Assignee: server-ops → aravind
nothing in the docs has stuff on what to do with specific problems like this.

iirc, this box was build to figure out some specific problem that the build folks were seeing on xservs, I am assuming this is the same problem.  Moving the bug to build and release.

Paging John about it as well.
Assignee: aravind → nobody
Component: Server Operations: Tinderbox Maintenance → Release Engineering
QA Contact: justin → release
We brought bm-xserve06 over today to see if we could reproduce bug#432471 happening on qm-xserve01. Let me poke around a little and see whats going on.
Assignee: nobody → joduinn
I'm not sure what's causing this. The machine appears to be configured correctly based on its passing of all the other reftests. The machine ran green (twice, the last time was the first run from when we put it on production) then turned orange immediately. Checkins during that range didn't appear significant.

Needs further investigation, but since it's the only machine currently running unittests on mac that aren't compromised, I recommend leaving it on the tinderbox and either ignoring the failing reftest or disabling it until we can do some deeper investigation.
(In reply to comment #3)
> I recommend leaving it on the
> tinderbox and either ignoring the failing reftest

I'm fine with ignoring it for now until we know more -- I mentioned this bug at the top of the tinderbox page, so people should see that and know to ignore this particular orange.
After the first initial green passing testrun on qm-xserve06, this machine is
consistently failing the same reftest. 

Josh and Gavin: any chance your changes could possibly have caused this
413292-1.html reftest failure?
From irc with robcee just now.

The same reftest which fails on qm-xserve06 is passing on qm-xserve01. However, we feel that qm-xserve01 is under enough suspicion for accuracy right now (in bug#432471 ), that we dont want to draw any conclusions from that. 

Thanks for updating the tinderbox page with this bug, I think that its the right thing to do. 
Not sure who best to work on this, putting this bug back in the pool.
Assignee: joduinn → nobody
See also bug 432292, qm-moz2mini01 has the same problem.
(In reply to comment #8)
> See also bug 432292, qm-moz2mini01 has the same problem.

So I guess that means Josh and Gavin's checkin yesterday couldn't have caused this (per comment 5).
(In reply to comment #9)
> (In reply to comment #8)
> > See also bug 432292, qm-moz2mini01 has the same problem.
> 
> So I guess that means Josh and Gavin's checkin yesterday couldn't have caused
> this (per comment 5).
> 
Agreed, nothing to do with Josh/Gavin's checkins yesterday. I didnt know about  the other bug#432292 until just now.

Not sure if this should be closed as a DUP of bug#432292 or tracked separately. However, nothing we can do with this, so reassigning to same component as bug#432292. 

If I'm missing something that we should be doing here, feel free to comment & reassign, ok?  
Component: Release Engineering → Layout: View Rendering
Product: mozilla.org → Core
QA Contact: release → layout.view-rendering
Version: other → unspecified
I tend to think that if no one's actively working on figuring this out, we should take this box off the tinderbox page.

Per comment 4, it made sense to me to leave it there for a bit, until we knew more, but I don't think it makes sense to leave it on a longer-term scale. There's not much benefit and there's moderate drawback (causing confusion & making tinderstatus addon be hard-orange) to having an always-failing tinderbox.

(With the exception that we're in RC1 lockdown and no one will be checking in for a bit anyway.)
I understand removing the boxes from the tree, to avoid tree confusion. But I also fear this is suppressing the symptoms of a possible real lurking bug. 

To me, its interesting when the same reftest fails out on two separate machines on two separate repos (qm-xserve06 on cvs 1.9/trunk, and also qm-moz2mini01 on hg mozilla-central). 

Could someone who understands reftest 413292-1.html help?
the other alternative is to disable the test on OS X as expected to be random. I could try a clobber on xserve06 to see if that helps, though really, I wouldn't expect it to.
Attached patch mark test as random-on-OS-X (obsolete) — Splinter Review
(In reply to comment #13)
> the other alternative is to disable the test on OS X as expected to be random.

Here's a patch to do that.
Comment on attachment 320556 [details] [diff] [review]
mark test as random-on-OS-X

a+ from me
Attachment #320556 - Flags: review?(dbaron)
Is marking the test as random going to fix a failure to load?  Is there a bug filed on fixing the underlying problem (as there should be for all failing tests)?
(In reply to comment #16)
> Is marking the test as random going to fix a failure to load?

Good point -- "skip-if" would probably be better than "random-if"

> Is there a bug
> filed on fixing the underlying problem (as there should be for all failing
> tests)?
 
Well, there's this bug here. :)  (That's initially what I had in mind when I filed this bug.)  But yeah, I'll file another bug for investigating / fixing the underlying issue.
(In reply to comment #17)
> > Is there a bug
> > filed on fixing the underlying problem (as there should be for all failing
> > tests)?
> 
> Well, there's this bug here. :)  (That's initially what I had in mind when I
> filed this bug.)  But yeah, I'll file another bug for investigating / fixing
> the underlying issue.

Filed bug 433538 on fixing the underlying problem.
Disabling checked in.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to comment #20)
> Disabling checked in. [to mozilla-central]

Disabling has now been checked in to CVS, too.

Checking in reftest.list;
/cvsroot/mozilla/layout/reftests/bugs/reftest.list,v  <--  reftest.list
new revision: 1.455; previous revision: 1.454
done

(qm-xserve06 pulls from CVS, so it's still been orange, but it should go green now that CVS is updated.)
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.