[Webkit-unassigned] [Bug 147339] New: Crash in WebCore::DocumentLoader::willSendRequest() with ContentFilter and AppCache

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=147339

            Bug ID: 147339
           Summary: Crash in WebCore::DocumentLoader::willSendRequest()
                    with ContentFilter and AppCache
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: All
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: beidson at apple.com

Crash in WebCore::DocumentLoader::willSendRequest() with ContentFilter and AppCache

#0    0x00000001050c1040 in WebCore::ResourceLoader::identifier() const at /Volumes/Data/git/OpenSource/Source/WebCore/loader/ResourceLoader.h:92
#1    0x00000001054b9174 in WebCore::DocumentLoader::willSendRequest(WebCore::ResourceRequest&, WebCore::ResourceResponse const&) at /Volumes/Data/git/OpenSource/Source/WebCore/loader/DocumentLoader.cpp:554
#2    0x00000001054b8ca0 in WebCore::DocumentLoader::redirectReceived(WebCore::CachedResource*, WebCore::ResourceRequest&, WebCore::ResourceResponse const&) at /Volumes/Data/git/OpenSource/Source/WebCore/loader/DocumentLoader.cpp:489
#3    0x00000001050c0088 in WebCore::CachedRawResource::didAddClient(WebCore::CachedResourceClient*) at /Volumes/Data/git/OpenSource/Source/WebCore/loader/cache/CachedRawResource.cpp:135
#4    0x00000001050c631c in WebCore::CachedResource::Callback::timerFired() at /Volumes/Data/git/OpenSource/Source/WebCore/loader/cache/CachedResource.cpp:779
...

The scenario is as follows:
- Content filters are on in Safari
- Visit a page that uses app cache, and has redirects for their main URL. Example is twitter.com, which uses app cache, and on iOS redirects to mobile.twitter.com
- When DocumentLoader adds itself as a client to the CachedRawResource for the main resource, the CachedResource doesn't actually add it synchronously. From CachedResource::addClientToSet:
        // Certain resources (especially XHRs and main resources) do crazy things if an asynchronous load returns
        // synchronously (e.g., scripts may not have set all the state they need to handle the load).
        // Therefore, rather than immediately sending callbacks on a cache hit like other CachedResources,
        // we schedule the callbacks and ensure we never finish synchronously.
        m_clientsAwaitingCallback.add(client, std::make_unique<Callback>(*this, *client));
- Before that timer fires, the main resource finishes loading, which clears the ResourceLoader from the CachedResource.
- Then the timer fires, actually adding the DocumentLoader as a client, and then all of the delegate callbacks are replayed.
- This includes the redirect, which redirects to a URL in the app cache, which sets up a substitute resource load and attempts to grab the load identifier for later use.

*phew*

Even though the steps that lead to this crash are well understood at this point, creating a layout test for it has proven to be an uphill battle so far.

There's also a further downstream crash where the existence of a ResourceLoader is incorrectly assumed. That will also be reflected in the upcoming patch.

<rdar://problem/21960398>

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150727/f48474eb/attachment.html>