Question

I’ve got a pretty gnarly technical problem and I’m hoping that there might be some Webkit experts around. I’m working on an iOS application for a client. Most of the application is HTML5 content served up in UIWebView controllers.

About a week ago, the QA team started reporting that the application crashes. We’ve been getting about 1 crash report a day for the last week. Unfortunately, they’re the kind of crash where no clear set of steps can be determined that consistently reproduce the crash. Strangely, some of those crash reports have been using old versions of the iOS code base — code that’s run successfully for months without anyone noticing this crash behaviour.

But what all the crash situations have in common is that they’re all running against an updated back-end serving up the latest version of the HTML web app pages. So it pretty-much seems that we’ve done something new on the server side that’s triggering something in the iOS code to crash.

The crash logs have been pretty consistent. Here’s the symbolicated log:

0   WebCore    0x33147ab0 WebCore::FrameLoader::cancelledError(WebCore::ResourceRequest const&) const + 4
1   WebCore    0x33070fbe WebCore::ResourceLoader::init(WebCore::ResourceRequest const&) + 166
2   WebCore    0x33070e66 WebCore::SubresourceLoader::startLoading() + 14
3   WebCore    0x33070c4e WebCore::ResourceLoadScheduler::servePendingRequests(WebCore::ResourceLoadScheduler::HostInformation*, WebCore::ResourceLoadPriority) + 46
4   WebCore    0x33076508 WebCore::ResourceLoadScheduler::servePendingRequests(WebCore::ResourceLoadPriority) + 36
5   WebCore    0x32fd38c8 WebCore::ThreadTimers::sharedTimerFiredInternal() + 92

(Most questions that discuss crashes in the WebCore are answered with a suggestion that you set the webview.delegate to nil in the dealloc method. That doesn’t seem to be our problem).

Now I have one theory (which I’ll talk about in a moment), but what I don’t have is clear evidence. So I grabbed the source from webkit.org and am trying to read enough of it to understand what the WebKit was doing at the time that it crashed. I don’t think I’m using quite the same version of WebKit source as in the iOS devices (we’ve seen this in 5.0.1 and 5.1.1 devices), the key methods seem to appear to reference downloading resources (like CSS and images) but there seems to be a null URL involved, so we end up calling cancelledError method.

The FrameLoader then does this:

ResourceError FrameLoader::cancelledError(const ResourceRequest& request) const
{
    ResourceError error = m_client->cancelledError(request);
    error.setIsCancellation(true);
    return error;
}

and it’s in this method that the app crashes with:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000008

which suggests to me that the m_client isn’t pointing at something valid.

Now, I do have a theory about what’s happening, just based on gut feel and circumstantial evidence.

Our UIWebView has a delegate that evaluates the URLs being loaded into the web view. In certain circumstances, we decide to launch new URLs in a separate ViewController, like so:

- (BOOL)webView:(UIWebView *)source shouldStartLoadWithRequest:(NSURLRequest *)request  navigationType:(UIWebViewNavigationType)navigationType 
{
    ...

    if ([self.popupStrategy shouldPopupURL:[request URL] fromCurrent:[source.request URL]]) {

        PopupTransitionViewController *popController = [self createPopupController:request];
        ... push it onto the navigation controller ...

    }
    ...
}

One of the key conditions that causes this popup strategy to return true occurs during a cross-domain link. That is to say, if the user taps on a link/icon and the target of that link is hosted by a third-party site, the app launches the new content in a different ViewController (for various reasons, including being able to get a nice native transition on cross-domain links).

One of the server-side changes that happened a few weeks ago is that the link href has been updated — the link now calls our main server, which sends back an HTTP redirect sending the client to the third-party site.

What I see in this case is that our popupStrategy gets called twice. The first time, it’s evaluating the URL to our main server, and the second time, it evaluates the third-party URL. In the second case, the strategy tells the UIWebView to load the request in a new ViewController. My thinking is that something in the Webkit code doesn’t always like that, and through some oddities of timing or whatnot, this somehow leads to a crash at some point.

This theory sticks with me because it’s based on new web loading behaviour that didn’t previously exist in our server code base, which conveniently fits the symptoms. My read of the Webkit code is that, in some of the methods referenced, Webkit seems to be doing some special processing when it sees cross-origin requests. But the crash has been impossible to reproduce on cue, so we don’t have a lot more to go on. But if the theory is true, I know a reasonable fix.

My hope is that someone has some familiarity with Webkit’s internals and can suggest:

a) how well this theory is supported by the Webkit stack-trace?

b) are there any other insights that anyone can see that are suggested by the stack trace I’m getting?

Answer 1

I ended up making code changes, rooted in the theory I described, above. After those changes were made, I didn’t see a recurrence of the crash. So the original theory looks to have been correct.