Bug 56537

Summary: REGRESSION (r80050-r80060): http/tests/appcache/online-fallback-layering.html failing on SnowLeopard Intel Release (WebKit2 Tests)
Product: WebKit Reporter: Adam Roben (:aroben) <aroben>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: ap, michaeln
Priority: P2 Keywords: InRadar, LayoutTestFailure, PlatformOnly, Regression
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.6   
URL: http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r81319%20(9764)/http/tests/appcache/online-fallback-layering-pretty-diff.html

Adam Roben (:aroben)
Reported 2011-03-16 22:38:17 PDT
http/tests/appcache/online-fallback-layering.html is failing on SnowLeopard Intel Release (WebKit2 Tests). See the URL for the diff. webkit-patch failure-reason says the regression happened in r80050-r80060. Did not fail: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28WebKit2%20Tests%29/builds/9154 Did fail: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28WebKit2%20Tests%29/builds/9155 This is only failing on SnowLeopard, not on Windows.
Attachments
Adam Roben (:aroben)
Comment 1 2011-03-16 23:36:00 PDT
Checked in expected failure results in r81329.
Sam Weinig
Comment 2 2011-03-16 23:37:16 PDT
Michael Nordman
Comment 3 2011-03-17 11:55:26 PDT
Here's the output of the test: Test that a network namespace trumps a fallback namespace where they overlap. Sanity check the presence of the fallback namespace, should get the fallback resource. unexpected status code FAIL - did not get the fallback resource The unexpected status code is telling... this is possibly a result of... https://bugs.webkit.org/show_bug.cgi?id=55500
Alexey Proskuryakov
Comment 4 2011-03-17 12:07:43 PDT
I don't see any related changes in r80050-r80060. I suspect that the test has been always failing on WebKit2 (it's been landed in r80036).
Michael Nordman
Comment 5 2011-03-17 13:23:51 PDT
(In reply to comment #4) > I suspect that the test has been always failing on WebKit2 (it's been landed in r80036). Seems likely. If timing is changed under WebKit2 such that the appcache must be loaded from storage instead of still being live in memory, it would fail in this way. Or the cache resides in storage from a previous test run and is loaded from disk instead of being newly created, it would fail in this way.
Note You need to log in before you can comment on or make changes to this bug.