阅读iOS Webkit崩溃堆栈跟踪

概述我有一个非常粗糙的技术问题,我希望可能会有一些Webkit专家.我正在为客户端开发iOS应用程序.大多数应用程序是在UIWebView控制器中提供的 HTML5内容. 大约一周前,QA团队开始报告应用程序崩溃.我们上周一天收到大约1份崩溃报告.不幸的是,它们是一种崩溃,在这种情况下,无法确定可以始终如一地重现崩溃的明确步骤.奇怪的是,其中一些崩溃报告一直在使用旧版本的iOS代码库 – 几个月来成功 我有一个非常粗糙的技术问题,我希望可能会有一些Webkit专家.我正在为客户端开发iOS应用程序.大多数应用程序是在UIWebVIEw控制器中提供的 HTML5内容.

大约一周前,QA团队开始报告应用程序崩溃.我们上周一天收到大约1份崩溃报告.不幸的是,它们是一种崩溃,在这种情况下,无法确定可以始终如一地重现崩溃的明确步骤.奇怪的是,其中一些崩溃报告一直在使用旧版本的iOS代码库 – 几个月来成功运行的代码,没有人注意到这种崩溃行为.

但是所有崩溃情况的共同之处在于它们都是针对提供最新版HTML网页应用页面的更新后端运行的.所以我们似乎已经在服务器端做了一些新的东西,它会触发iOS代码中的某些东西崩溃.

崩溃日志非常一致.这是符号化的日志：

0   WebCore    0x33147ab0 WebCore::FrameLoader::cancelledError(WebCore::ResourceRequest const&) const + 41   WebCore    0x33070fbe WebCore::ResourceLoader::init(WebCore::ResourceRequest const&) + 1662   WebCore    0x33070e66 WebCore::SubresourceLoader::startLoading() + 143   WebCore    0x33070c4e WebCore::ResourceLoadScheduler::servePendingRequests(WebCore::ResourceLoadScheduler::Hostinformation*,WebCore::ResourceLoadPriority) + 464   WebCore    0x33076508 WebCore::ResourceLoadScheduler::servePendingRequests(WebCore::ResourceLoadPriority) + 365   WebCore    0x32fd38c8 WebCore::ThreadTimers::sharedTimerFiredInternal() + 92

(在WebCore中讨论崩溃的大多数问题的答案是建议你在dealloc方法中将webvIEw.delegate设置为nil.这似乎不是我们的问题).

现在我有一个理论(我将在稍后讨论),但我没有的是明确的证据.所以我抓住了webkit.org的源代码,并试图阅读足够的内容来了解​​WebKit在崩溃时正在做什么.我不认为我使用的是与iOS设备完全相同的WebKit源版本(我们在5.0.1和5.1.1设备中看到过这一点),关键方法似乎似乎引用了下载资源(如CSS和图像)但似乎涉及到一个空URL,所以我们最终调用cancelledError方法.

然后FrameLoader执行此 *** 作：

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

并且在这种方法中应用程序崩溃：

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

这告诉我m_clIEnt没有指向有效的东西.

现在,我确实有一个关于发生了什么的理论,只是基于直觉和间接证据.

我们的UIWebVIEw有一个委托,用于评估加载到Web视图中的URL.在某些情况下,我们决定在单独的VIEwController中启动新的URL,如下所示：

- (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 ...    }    ...}

导致此d出策略返回true的关键条件之一发生在跨域链接期间.也就是说,如果用户点击链接/图标并且该链接的目标由第三方站点托管,则该应用程序在不同的VIEwController中启动新内容(出于各种原因,包括能够获得跨域链接上的好的本机转换).

几周前发生的服务器端更改之一是链接href已更新 – 链接现在调用我们的主服务器,后者发回http重定向,将客户端发送到第三方站点.

我在这种情况下看到的是我们的popupStrategy被调用了两次.第一次,它正在评估我们的主服务器的URL,第二次,它评估第三方URL.在第二种情况下,策略告诉UIWebVIEw在新的VIEwController中加载请求.我的想法是Webkit代码中的某些东西并不总是那样,并且通过一些奇怪的时间或诸如此类的东西,这在某种程度上会导致崩溃.

这个理论坚持我,因为它基于我们的服务器代码库中以前不存在的新的Web加载行为,它可以方便地适应症状.我读到的Webkit代码是,在一些引用的方法中,Webkit似乎在看到跨源请求时进行了一些特殊的处理.但是崩溃已经无法重现了,所以我们没有更多的东西要继续下去.但如果理论是真的,我知道一个合理的解决方案.

我希望有人熟悉Webkit的内部结构,并建议：

a)Webkit堆栈跟踪对该理论的支持程度如何？

b)有没有任何其他见解,任何人都可以看到我得到的堆栈跟踪建议？

解决方法 我最终根据上面描述的理论进行了代码更改.在做出这些改变之后,我没有看到崩溃再次发生.所以原始理论看起来是正确的. 总结

以上是内存溢出为你收集整理的阅读iOS Webkit崩溃堆栈跟踪全部内容，希望文章能够帮你解决阅读iOS Webkit崩溃堆栈跟踪所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。