Bug 45097

Summary: Snow Leopard Release Tests buildslave failing on fast/css/display-none-inline-style-change-crash
Product: WebKit Reporter: Matthew Willis (lilmatt) <lilmatt>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, eric, hyatt, sam, timothy
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.6   
Attachments:
Description Flags
Attempt to fix flaky test by adding layoutTestController.waitUntilDone() and ...notifyDone() none

Description Matthew Willis (lilmatt) 2010-09-02 02:38:10 PDT
The Snow Leopard Release Tests buildslave has been failing on fast/css/display-none-inline-style-change-crash since Tuesday night.

http://build.webkit.org/waterfall?show=SnowLeopard%20Intel%20Release%20(Tests)&last_time=1283326000

The test is failing, not because the original bug for which it was written has returned, but because of this now (unexpectedly) appearing in the output.

> ALERT: 1 rule(s) were returned from getMatchedCSSRules, expected zero.

build 16778 appears to work and 16779 doesn't.  There's a pretty major change w/r/t CSS in r66577.
Comment 1 Matthew Willis (lilmatt) 2010-09-02 02:39:05 PDT
(In reply to comment #0)
> build 16778 appears to work and 16779 doesn't.

Clarification: build 16778 passes the test and 16779 doesn't.  The builds otherwise "work".
Comment 2 Matthew Willis (lilmatt) 2010-09-02 03:12:16 PDT
I searched the code base for the string found in the output
> were returned from getMatchedCSSRules

I only found it in fast/css/disabled-author-styles.html
However the test that's failing is fast/css/display-none-inline-style-change-crash.html

There don't appear to be any common tag IDs or function names.

Somehow the output from one test is leaking into the other, and with some frequency!
Comment 3 Matthew Willis (lilmatt) 2010-09-02 03:15:08 PDT
Note that the tests are adjacent to each other in alpha order, so perhaps one test's output is being attributed to the following test. Perhaps the FIRST test is the one that's failing, and there's a bug in the testing framework that is letting the output "leak" into the next test.
Comment 4 Matthew Willis (lilmatt) 2010-09-02 03:43:25 PDT
eseidel suggested CCing the authors of the two tests (hyatt and mitz)

Link to actual failed test output diff (cause it sucked to find it): http://bit.ly/agx1fs
Comment 5 Matthew Willis (lilmatt) 2010-09-02 12:54:36 PDT
Created attachment 66400 [details]
Attempt to fix flaky test by adding layoutTestController.waitUntilDone() and ...notifyDone()
Comment 6 Eric Seidel (no email) 2010-09-02 13:07:02 PDT
Hmm..  I suspect it's a more recent regression.  The timeout, if anything, will just make it fail more consistently as the right test instead of bleeding into the next test.
Comment 7 Eric Seidel (no email) 2010-09-02 13:07:51 PDT
Comment on attachment 66400 [details]
Attempt to fix flaky test by adding layoutTestController.waitUntilDone() and ...notifyDone()

I'm all for making this test more reliable.  So lets give this a shot.
Comment 8 Eric Seidel (no email) 2010-09-02 13:45:34 PDT
Comment on attachment 66400 [details]
Attempt to fix flaky test by adding layoutTestController.waitUntilDone() and ...notifyDone()

Clearing flags on attachment: 66400

Committed r66684: <http://trac.webkit.org/changeset/66684>
Comment 9 Eric Seidel (no email) 2010-09-02 13:45:39 PDT
All reviewed patches have been landed.  Closing bug.