Bug 45097 - Snow Leopard Release Tests buildslave failing on fast/css/display-none-inline-style-change-crash
Summary: Snow Leopard Release Tests buildslave failing on fast/css/display-none-inline...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.6
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-02 02:38 PDT by Matthew Willis (lilmatt)
Modified: 2010-09-02 13:45 PDT (History)
5 users (show)

See Also:


Attachments
Attempt to fix flaky test by adding layoutTestController.waitUntilDone() and ...notifyDone() (1.67 KB, patch)
2010-09-02 12:54 PDT, Matthew Willis (lilmatt)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.