http/tests/contentfiltering/load-substitute-data-from-appcache.html and http/tests/appcache/decide-navigation-policy-after-delay.html crash in DocumentLoader::dataReceived sometimes

• Component: WebCore Misc.
• Status: NEW ---

[Alexey Proskuryakov]

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)

[Alexey Proskuryakov]

rdar://problem/22611076

[Alexey Proskuryakov]

<rdar://problem/22729876>

[Andy Estes]

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.

[Andy Estes]

Created attachment 261611 [details]
Patch

[Build Bot]

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

[Build Bot]

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

[Andy Estes]

Created attachment 261615 [details]
add a similar test to isolate the problem

[Alexey Proskuryakov]

Comment on attachment 261615 [details]
add a similar test to isolate the problem

Is this completely unreproducible locally? What did you try?

[Andy Estes]

(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.

[Andy Estes]

I also tried with --order=random.

[Alexey Proskuryakov]

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.

[Andy Estes]

Committed r190041: <http://trac.webkit.org/changeset/190041>

[Alexey Proskuryakov]

*** Bug 149723 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

Marked both tests as flaky in r190552. It was tricky since they had complicated and different skip/unskip chains.

[Alexey Proskuryakov]

This seems like it stopped happening some time earlier in 2016.

[Alexey Proskuryakov]

(and then these same tests started to crash in a different way, frequently)