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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Nov 6 00:13:20 PST 2014


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

Alexey Proskuryakov <ap at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andersca at apple.com,
                   |                            |darin at apple.com

--- Comment #3 from Alexey Proskuryakov <ap at webkit.org> ---
Daniel, are the crashes that you are observing in MarsEdit also happening when closing windows?

In the MiniBrowser case, it appears that WebView is doing pretty crazy things, which stretch my understanding of Objective-C runtime. Here is what happens:

1. The window gets closed, which deallocates WK1BrowserWindowController.
2. This eventually leads to WebView refcount dropping to 0, and -[WebView dealloc] being called from an autorelease pool draining loop.
3. -[WebView dealloc] calls -[WebView close], which calls -[WebView _close].
4. -[WebView _close] does two sketchy things:
 - Post a WebViewWillCloseNotification notification. This retains self, which is already in the process of being deallocated. A notification listener can of course perform arbitrary work, although in the case of MiniBrowser, there is no listener.
 - Execute JavaScript unload event handler, which can run arbitrary JavaScript. In the case of onedrive.live.com, it makes a synchronous XMLHttpRequest, which makes the WebView get retained and autoreleased a few more times.
5. Once done, returns to the autorelease draining loop, and hits an overrelease.

I do not know for sure, but I'm assuming that is illegal to retain an object from inside -dealloc, and that it somehow causes the overrelease (despite all retain/release pairs being balanced).

One way to fix MiniBrowser is to call -[WebView close] before -[WebView release]. But that's certainly fragile, and not what documentation for -close says.

I'm not sure what the real WebKit fix would be.

-- 
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/20141106/104e3b2d/attachment-0002.html>


More information about the webkit-unassigned mailing list