I saw http/tests/contentfiltering/load-substitute-data-from-appcache.html (a new test) crash several times on Yosemite with a release assert: https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Ftests%2Fcontentfiltering%2Fload-substitute-data-from-appcache.html 0 com.apple.JavaScriptCore 0x000000010cbb4797 WTFCrash + 39 1 com.apple.WebCore 0x000000010eb4e4ce WebCore::DocumentLoader::dataReceived(WebCore::CachedResource*, char const*, int) + 206 (DocumentLoader.cpp:864) 2 com.apple.WebCore 0x000000010eb4dfed WebCore::DocumentLoader::continueAfterContentPolicy(WebCore::PolicyAction) + 1773 (DocumentLoader.cpp:753) 3 com.apple.WebCore 0x000000010eb4d680 WebCore::DocumentLoader::responseReceived(WebCore::CachedResource*, WebCore::ResourceResponse const&) + 1968 (DocumentLoader.cpp:660) 4 com.apple.WebCore 0x000000010e841f20 WebCore::ContentFilter::responseReceived(WebCore::CachedResource*, WebCore::ResourceResponse const&) + 432 (ContentFilter.cpp:163) 5 com.apple.WebCore 0x000000010e70e189 WebCore::CachedRawResource::responseReceived(WebCore::ResourceResponse const&) + 201 (CachedRawResource.cpp:185) 6 com.apple.WebCore 0x000000011040475f WebCore::SubresourceLoader::didReceiveResponse(WebCore::ResourceResponse const&) + 767 (SubresourceLoader.cpp:232) 7 com.apple.WebKit 0x00000001098c4c92 WebKit::WebResourceLoader::didReceiveResponse(WebCore::ResourceResponse const&, bool) + 306 (WebResourceLoader.cpp:130)
rdar://problem/22611076
<rdar://problem/22729876>
I suspect this assertion would be hit even if Content Filtering wasn't enabled. The test decides navigation policy asynchronously in order mimic iOS Safari's behavior, so the response is sometimes received before navigation policy is decided. When loading substitute data, dataReceived() is called in continueAfterContentPolicy() with a null CachedResource, and it asserts that m_mainResource has already been set to 0 in continueAfterNavigationPolicy(): ASSERT_UNUSED(resource, resource == m_mainResource); I'm going to upload this same test without Content Filtering enabled to verify my assumption that the crash will still sometimes occur.
Created attachment 261611 [details] Patch
Comment on attachment 261611 [details] Patch Attachment 261611 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/190910 New failing tests: http/tests/appcache/decide-navigation-policy-after-delay.html
Created attachment 261614 [details] Archive of layout-test-results from ews102 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-mavericks Platform: Mac OS X 10.9.5
Created attachment 261615 [details] add a similar test to isolate the problem
Comment on attachment 261615 [details] add a similar test to isolate the problem Is this completely unreproducible locally? What did you try?
(In reply to comment #8) > Comment on attachment 261615 [details] > Patch > > Is this completely unreproducible locally? What did you try? I wasn't able to reproduce locally after running the tests in http/tests/contentfiltering/ for 100 iterations, but it seems to crash on the bots at least once a day. I was planning to land this and check for crashes tomorrow.
I also tried with --order=random.
It often helps to simulate full CPU load with --fully-parallel, possibly even overcommitting with --child-processes=<more than it normally starts>. > I was planning to land this and check for crashes tomorrow. Sure.
Committed r190041: <http://trac.webkit.org/changeset/190041>
*** Bug 149723 has been marked as a duplicate of this bug. ***
Marked both tests as flaky in r190552. It was tricky since they had complicated and different skip/unskip chains.
This seems like it stopped happening some time earlier in 2016.
(and then these same tests started to crash in a different way, frequently)