आईओएस वेबकिट क्रैश स्टैक ट्रेस

Question

पढ़ना मुझे एक बहुत ही गहन तकनीकी समस्या मिली है और मुझे उम्मीद है कि कुछ वेबकिट विशेषज्ञ हो सकते हैं। मैं एक ग्राहक के लिए एक आईओएस आवेदन पर काम कर रहा हूँ। अधिकांश एप्लिकेशन UIWebView नियंत्रकों में HTML5 सामग्री की सेवा की गई है।

लगभग एक सप्ताह पहले, क्यूए टीम ने रिपोर्टिंग शुरू कर दी थी कि एप्लिकेशन क्रैश हो गया है। हमें पिछले सप्ताह के लिए एक दिन में लगभग 1 क्रैश रिपोर्ट मिल रही है। दुर्भाग्यवश, वे दुर्घटनाग्रस्त हैं जहां कदमों का कोई स्पष्ट सेट निर्धारित नहीं किया जा सकता है जो लगातार क्रैश को पुन: पेश करता है। आश्चर्यजनक रूप से, उनमें से कुछ क्रैश रिपोर्ट आईओएस कोड बेस के पुराने संस्करणों का उपयोग कर रही हैं - कोड जो इस क्रैश व्यवहार को ध्यान में रखते हुए महीनों तक सफलतापूर्वक चलाया जाता है।

लेकिन सभी क्रैश स्थितियों में आम बात यह है कि वे सभी अपडेट किए गए बैक-एंड के खिलाफ चल रहे हैं जो HTML वेब ऐप पृष्ठों के नवीनतम संस्करण की सेवा कर रहे हैं। तो यह बहुत अधिक लगता है कि हमने सर्वर पक्ष पर कुछ नया किया है जो आईओएस कोड में क्रैश होने के लिए कुछ ट्रिगर कर रहा है।

क्रैश लॉग काफी सुसंगत रहे हैं। यहाँ symbolicated लॉग है: (। अधिकांश प्रश्नों पर चर्चा WebCore में दुर्घटनाओं एक सुझाव है कि आप dealloc विधि में नहीं के बराबर करने के लिए webview.delegate सेट के साथ उत्तर दिया जाता है कि हमारे समस्या हो प्रतीत नहीं होता है)

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 

।

अब मेरे पास एक सिद्धांत है (जो मैं एक पल में बात करूंगा), लेकिन जो मेरे पास नहीं है वह स्पष्ट सबूत है। इसलिए मैंने webkit.org से स्रोत को पकड़ लिया और यह समझने के लिए पर्याप्त रूप से पढ़ने की कोशिश कर रहा हूं कि वेबकिट उस समय क्रैश होने पर क्या कर रहा था। मुझे नहीं लगता कि मैं आईओएस डिवाइसों में वेबकिट स्रोत के समान संस्करण का उपयोग कर रहा हूं (हमने इसे 5.0.1 और 5.1.1 डिवाइसों में देखा है), संसाधनों को डाउनलोड करने के संदर्भ में प्रमुख विधियां दिखाई देती हैं (जैसे सीएसएस और छवियों) लेकिन लगता है कि एक शून्य यूआरएल शामिल है, इसलिए हम कॉलिंग रद्द कर सकते हैं त्रुटि विधि।

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 में एक प्रतिनिधि है जो वेब दृश्य में लोड होने वाले यूआरएल का मूल्यांकन करता है। कुछ परिस्थितियों में, हम तो जैसे एक अलग 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 ... 

    } 
    ... 
} 

कुंजी की स्थिति है कि सच लौटने के लिए इस पॉपअप रणनीति कारणों में से एक एक क्रॉस-डोमेन लिंक के दौरान होता है। ऐसा कहने के लिए, यदि उपयोगकर्ता किसी लिंक/आइकन पर टैप करता है और उस लिंक का लक्ष्य किसी तृतीय-पक्ष साइट द्वारा होस्ट किया जाता है, तो ऐप नई सामग्री को एक अलग व्यू कंट्रोलर में लॉन्च करता है (विभिन्न कारणों से, जिसमें एक प्राप्त करने में सक्षम होना शामिल है क्रॉस-डोमेन लिंक पर अच्छा देशी संक्रमण)।

कुछ हफ्ते पहले सर्वर-साइड परिवर्तनों में से एक यह है कि लिंक href अपडेट किया गया है - लिंक अब हमारे मुख्य सर्वर को कॉल करता है, जो क्लाइंट को तृतीय-पक्ष साइट पर भेजकर एक HTTP रीडायरेक्ट भेजता है ।

इस मामले में मैं जो देखता हूं वह यह है कि हमारे पॉपअपस्ट्रेटी को दो बार बुलाया जाता है।पहली बार, यह हमारे मुख्य सर्वर पर यूआरएल का मूल्यांकन कर रहा है, और दूसरी बार, यह तीसरे पक्ष के यूआरएल का मूल्यांकन करता है। दूसरे मामले में, रणनीति UIWebView को नए व्यू कंट्रोलर में अनुरोध लोड करने के लिए कहती है। मेरी सोच यह है कि वेबकिट कोड में कुछ ऐसा हमेशा पसंद नहीं करता है, और समय या चीज़ों की कुछ विषमताओं के माध्यम से, यह किसी भी समय किसी दुर्घटना की ओर जाता है।

यह सिद्धांत मेरे साथ चिपक जाता है क्योंकि यह नए वेब लोडिंग व्यवहार पर आधारित है जो पहले हमारे सर्वर कोड बेस में मौजूद नहीं था, जो आसानी से लक्षणों को फिट करता है। वेबकिट कोड का मेरा पठन यह है कि, कुछ विधियों में संदर्भित किया गया है, जब वेबकिट क्रॉस-मूल अनुरोधों को देखता है तो कुछ विशेष प्रसंस्करण कर रहा है। लेकिन क्यू पर पुनरुत्पादन करना दुर्घटनाग्रस्त हो गया है, इसलिए हमारे पास आगे बढ़ने के लिए बहुत कुछ नहीं है। लेकिन अगर सिद्धांत सत्य है, तो मुझे एक उचित फिक्स पता है।

मेरे आशा किसी वेबकिट के internals के साथ कुछ परिचित है और सुझाव है कि कर सकते हैं:

क) कैसे अच्छी तरह से इस सिद्धांत वेबकिट ढेर का पता लगाने के द्वारा समर्थित है?

बी) क्या कोई अन्य अंतर्दृष्टि है कि कोई भी देख सकता है कि मुझे स्टैक ट्रेस द्वारा सुझाया जा रहा है?

Answer 1

मैंने ऊपर वर्णित सिद्धांत में रूट कोड कोड बदलना समाप्त कर दिया। उन परिवर्तनों के बाद, मुझे दुर्घटना की पुनरावृत्ति दिखाई नहीं दे रही थी। तो मूल सिद्धांत सही होना प्रतीत होता है।