Summary: | http/tests/contentfiltering/load-substitute-data-from-appcache.html and http/tests/appcache/decide-navigation-policy-after-delay.html crash in DocumentLoader::dataReceived sometimes | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||||||
Component: | WebCore Misc. | Assignee: | Andy Estes <aestes> | ||||||||
Status: | NEW --- | ||||||||||
Severity: | Normal | CC: | aestes, buildbot, ddkilzer, rniwa, ryanhaddad | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | Other | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Alexey Proskuryakov
2015-09-04 23:40:47 PDT
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) |