[Webkit-unassigned] [Bug 138443] New: Crash in NSURLConnectionInternal, messaging released WebView

[bugzilla-daemon at webkit.org]

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

            Bug ID: 138443
           Summary: Crash in NSURLConnectionInternal, messaging released
                    WebView
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jalkut at red-sweater.com

Created attachment 241058
  --> https://bugs.webkit.org/attachment.cgi?id=241058&action=review
Crash log for the typical crashing case described here

I've been looking into a crash that affects real-world users of my app, MarsEdit. The nuance of this bug is that a customer experiences crashes in my app (which features a WebView-based rich editor) only when they embed HTML code from Microsoft's "OneDrive" service.

I have confirmed that the crash is not specific to my app by reproducing it easily with a trunk build of WebKit, running MiniBrowser in WebKitLegacy mode:

1. Build WebKit from the command line: ./Tools/Scripts/build-webkit --debug
2. Run ./Tools/Scripts/run-minibrowser --debug
3. Open a new window in MiniBrowser and load this URL:

https://onedrive.live.com/embed?cid=481F46B257143886&resid=481F46B257143886%21125&authkey=ADg4zT2NXK6xtIw&em=2

3. Close the window while the view is loading or shortly after it has completed.

The bug reproduces pretty easily upon closing the window, but to make it even more likely to occur, try closing it in the midst of the view's content loading.

I'm attaching a crash log that shows the issue is typically that the WebView associated with the closed window is deallocated by the time an active NSURLConnection's delegate dispatch attempts to call back to it. I'm a little confused actually because the crash often appears to occur upon release after a retain by the NSURLConnection, so it may come down to an issue in NSURLConnection, but I saw a few things in ResourceHandleMac that had me concerned:

1. In ResourceHandle::~ResourceHandle, cancel() is not called. It seems like it should be to ensure that any pending NSURLConnection tracked by m_connection is stopped.

2. I suspect that beyond calling cancel, it may be necessary to mirror the calls to scheduleInRunLoop:... from ResourceHandle::start, with calls to unscheduleFromRunLoop:... documentation in NSURLConnection is a little contradictory but I think the safest best is to unschedule the connection from runloops it was scheduled to, to avoid any unwanted delegate dispatch after the delegate may be gone.

3. I noticed that ResourceHandleMac implements ResourceHandle::schedule and ResourceHandle::unschedule, but these methods are not reached in typical cases I've run in MiniBrowser. I wonder if these are vestigial from a past implementation that didn't rely upon the scheduling that occurs in ::start? If so they can probably be removed to help clarify the obligation of ResourceHandleMac to unschedule m_connection only from the runloops it scheduled in ::start.

Now the bad news: even after adding to ResourceHandle::~ResourceHandle a call to close() and a mirror of the code from ::start that schedules the connection on the runloop, except to unschedule from the run loop, the crashing behavior is still occurring for me. So while I think the analysis above has some truth to it, I clearly don't understand the situation well enough to completely remedy the problem.

I hope my initial work helps somebody more experienced with ResourceHandleMac to speculate about what's going on in this crash and hopefully come up with a fix. If you have advice for me to pursue creation of a patch on my own I'd be happy to help with that.

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