iOS Webkitのクラッシュスタックトレースを読む

Question

技術的にかなりの問題があり、Webkitの専門家がいらっしゃることを期待しています。私はクライアント用のiOSアプリケーションで作業しています。アプリケーションのほとんどは、UIWebViewコントローラで提供されるHTML5コンテンツです。

約1週間前に、QAチームはアプリケーションのクラッシュを報告し始めました。先週、1日に1件のクラッシュレポートを取得しています。残念なことに、クラッシュを一貫して再現する明確なステップが決まらないクラッシュのようなものです。不思議なことに、これらのクラッシュレポートのいくつかは、このクラッシュ動作に気付かれずに何ヶ月もうまく動作していた古いバージョンのiOSコードベースコードを使用していました。

しかし、すべてのクラッシュ状況に共通しているのは、HTML Webアプリケーションページの最新バージョンを提供する更新されたバックエンドに対してすべて実行されているということです。だから、私たちがサーバー側で何か新しいことをしたことは、iOSコードの中でクラッシュするようなものを引き起こしているように思えます。

クラッシュログはかなり一貫しています。ここsymbolicatedログです：

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 

（WebCoreにクラッシュを議論するほとんどの質問は、あなたがdeallocメソッドでnilにwebview.delegateを設定する提案と答えている私たちの問題であると思わないこと。） 。

今私は1つの理論を持っていますが、私には明らかな証拠はありません。だから私はwebkit.orgからソースを手に入れ、クラッシュした時点でWebKitがやっていたことを理解するために十分に読み込もうとしています。私はiOSデバイスと同じバージョンのWebKitソースを使用しているとは思わないが（5.0.1と5.1.1のデバイスでこれを見てきた）、主要な方法はリソースのダウンロードを参照するように見えるCSSと画像）が含まれていますが、nullのURLが含まれているようですので、canceledErrorメソッドを呼び出すことになります。

FrameLoaderは、この行います

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

を、それが持つアプリがクラッシュし、この方法ではあります：m_clientが有効なものを指していないことを私に

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

を示唆しています。

今、私は、何が起こっているかについての理論を持っています。ちょうど腸の感情と状況証拠に基づいています。

私たちのUIWebViewには、Webビューに読み込まれる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 ... 

    } 
    ... 
} 

ワン：特定の状況では、我々はそうのように、独立したのViewControllerに新しいURLを起動することを決定しました。つまり、ユーザーがリンク/アイコンをタップし、そのリンクのターゲットが第三者のサイトによってホストされている場合、アプリは別のViewControllerで新しいコンテンツを起動します（さまざまな理由により、クロスドメインリンク上の素敵なネイティブな移行）。

数週間前に起こったサーバー側の変更の1つは、リンクhrefが更新されたことです。このリンクでは、クライアントをサードパーティのサイトに送信するHTTPリダイレクトを返すメインサーバーが呼び出されます。

私がこのケースで見るのは、私たちのpopupStrategyが2回呼び出されるということです。初めて、メインサーバーへのURLを評価し、2回目にはサードパーティのURLを評価します。 2番目のケースでは、ストラテジは、新しいViewControllerに要求をロードするようにUIWebViewに指示します。私の考えは、Webkitコード内の何かがいつもそうであるとは限りませんし、タイミングやその他の何らかの奇妙なことによって、何らかの点でクラッシュすることがあります。

この理論は、私たちのサーバコードベースに以前は存在しなかった新しいウェブローディングの振る舞いに基づいているので、私には当てはまります。私がWebkitのコードを読んだのは、参照されているいくつかの方法では、Webkitが原点を越えた​​要求を見るときに特別な処理を行っているようです。しかし、クラッシュはキューで再現することが不可能であったので、我々はさらに進める必要はありません。しかし、理論が真実なら、私は妥当な修正を知っています。

私の希望は、誰かがWebKitの内部である程度の知識を持っていると示唆することができるということです。

a）は、この理論はWebkitのスタック・トレースによってサポートされてどれだけ？

b）他の洞察は誰もが私が得ているスタックトレースによって示唆されることがわかりますか？

Answer 1

上記の理論に根差してコードの変更が行われました。これらの変更が行われた後、私はクラッシュの再発は見られませんでした。元の理論は正しかったようです。