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

[bugzilla-daemon at webkit.org]

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

--- Comment #12 from Daniel Jalkut <jalkut at red-sweater.com> ---
OK, I think I've figured out what's going on on a more fine-grained basis. Alexey you were right in general about what was going on at dealloc time, but what I've additionally confirmed (couldn't tell if you already knew this from your description) is that the activity leading to an autorelease of the WebView during -dealloc is caused by the resource loading infrastructure of the WebView itself.

The JavaScript from onedrive.com that ends up issuing the xmlHTTPRequest resource load triggers a call to -[WebView _addObject:forIdentifier:], which upon finding there are no open requests, retains itself on the assumption that it will balance the retain with an autorelease when the load is finished.

I think this would all be fine except that as a further consequence of shutting down the web view, active requests (of which there is now one) are forcibly shutdown, leading to an immediate, mirrored call to -[WebView _removeObjectForIdentifier:], which upon seeing that the last request has been removed from the identifier map, follows through on its commitment to [self autorelease]. (see attached DeallocAutorelease.txt)

Because this is all happening within the same run loop cycle as the -dealloc method, the WebView instance still exists at the point the retain and autorelease messages are sent. But very shortly the end of the -dealloc method is reached, [super dealloc] is called, and the autorelease pool holding the WebView is not released until after the WebView is well and truly gone.

So in short: WebView's dealloc has complicated enough implications for the active Web runtime that some care must be taken so that the view itself doesn't get put on the autorelease pool, because it won't be drained until after dealloc is done.

One solution that comes to mind is WebView's dealloc method could pop its own autorelease pool onto the stack to capture any of this behavior, releasing before it in turn calls through to -[super dealloc]. I've confirmed that this does alleviate the crashing behavior that led me to report this bug, so I'm attaching as a patch, though I can appreciate you may want to approach the problem in another way.

-- 
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/9e41d3a4/attachment-0002.html>