A significant source of UIWebView-related crashes in Chrome for iOS (based on automated crash collection) is a stack that looks like this, or some similar variation with the same top: Thread 18 CRASHED [EXC_BAD_ACCESS / KERN_INVALID_ADDRESS @ 0xffffffffc2c80000] MAGIC SIGNATURE THREAD 0x320a8cc2 [WebCore + 0x0000ecc2 ] WebCore::StyleResolver::loadPendingImages() 0x320d9a55 [WebCore + 0x0003fa55 ] WebCore::CachedResourceRequest::~CachedResourceRequest() 0x329c321f [WebCore + 0x0092921f ] WebCore::StyleResolver::applyMatchedProperties(WebCore::StyleResolver::MatchResult const&, WebCore::Element const*, WebCore::StyleResolver::ShouldUseMatchedPropertiesCache) 0x320a9eb5 [WebCore + 0x0000feb5 ] WebCore::StyleResolver::styleForElement(WebCore::Element*, WebCore::RenderStyle*, WebCore::StyleSharingBehavior, WebCore::RuleMatchingBehavior, WebCore::RenderRegion*) 0x32157b3b [WebCore + 0x000bdb3b ] WebCore::Document::styleForElementIgnoringPendingStylesheets(WebCore::Element*) 0x32157a37 [WebCore + 0x000bda37 ] WebCore::Element::computedStyle(WebCore::PseudoId) 0x322fe2a9 [WebCore + 0x002642a9 ] WebCore::computeRenderStyleForProperty(WebCore::Node*, WebCore::PseudoId, WebCore::CSSPropertyID) 0x32190d23 [WebCore + 0x000f6d23 ] WebCore::ComputedStyleExtractor::propertyValue(WebCore::CSSPropertyID, WebCore::EUpdateLayout) const 0x32190bd3 [WebCore + 0x000f6bd3 ] WebCore::CSSComputedStyleDeclaration::getPropertyCSSValueInternal(WebCore::CSSPropertyID) 0x32190333 [WebCore + 0x000f6333 ] WebCore::JSCSSStyleDeclaration::getOwnPropertySlotDelegate(JSC::ExecState*, JSC::PropertyName, JSC::PropertySlot&) 0x325c3a51 [WebCore + 0x00529a51 ] WebCore::JSCSSStyleDeclaration::getOwnPropertySlot(JSC::JSObject*, JSC::ExecState*, JSC::PropertyName, JSC::PropertySlot&) 0x27e0c65b [JavaScriptCore + 0x0006665b ] JSC::LLInt::getByVal(JSC::ExecState*, JSC::JSValue, JSC::JSValue) 0x27defe21 [JavaScriptCore + 0x00049e21 ] llint_slow_path_get_by_val 0x2801bc4f [JavaScriptCore + 0x00275c4f ] llint_entry 0x2801de77 [JavaScriptCore + 0x00277e77 ] llint_entry 0x2801de77 [JavaScriptCore + 0x00277e77 ] llint_entry 0x2801dec5 [JavaScriptCore + 0x00277ec5 ] llint_entry 0x2801dec5 [JavaScriptCore + 0x00277ec5 ] llint_entry 0x28018d7d [JavaScriptCore + 0x00272d7d ] callToJavaScript 0x27fa9653 [JavaScriptCore + 0x00203653 ] JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) 0x27df94ad [JavaScriptCore + 0x000534ad ] JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 0x27eecb0f [JavaScriptCore + 0x00146b0f ] JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, JSC::JSValue*) 0x321f9e81 [WebCore + 0x0015fe81 ] WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) 0x321cb299 [WebCore + 0x00131299 ] WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1ul, WTF::CrashOnOverflow>&) 0x321281d1 [WebCore + 0x0008e1d1 ] WebCore::EventTarget::fireEventListeners(WebCore::Event*) 0x324121ad [WebCore + 0x003781ad ] WebCore::EventDispatcher::dispatchEvent(WebCore::Node*, WTF::PassRefPtr<WebCore::Event>) 0x32128063 [WebCore + 0x0008e063 ] WebCore::Node::dispatchEvent(WTF::PassRefPtr<WebCore::Event>) 0x323711a1 [WebCore + 0x002d71a1 ] WebCore::DocumentEventQueue::dispatchEvent(WebCore::Event&) 0x321d2da5 [WebCore + 0x00138da5 ] WebCore::DocumentEventQueue::pendingEventTimerFired() 0x320b7a13 [WebCore + 0x0001da13 ] WebCore::ThreadTimers::sharedTimerFiredInternal() 0x320b7967 [WebCore + 0x0001d967 ] WebCore::timerFired(__CFRunLoopTimer*, void*) 0x26bae515 [CoreFoundation + 0x000ce515 ] __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ We've had some luck with the following repro steps: 1. Open Chrome on iOS 2. Load www.smh.com.au 3. Open any article 4. Scroll through the page, then press the browser back button but it's not completely reliable. If there's any more useful information we can provide from our aggregate data, please let us know. This stack is from iOS 8.1, but crashes with essentially the same top frames date back to at least iOS 7. This is also filed as rdar://12708566
> This is also filed as rdar://12708566 rdar://12708566 is expected to be fixed via bug 127034, and the fix is present in iOS 8.0. Could you please file a new Radar?
(In reply to comment #1) > Could you please file a new Radar? Done: rdar://19014421
(In reply to comment #2) > (In reply to comment #1) > > Could you please file a new Radar? > > Done: rdar://19014421 Please attach full crash logs to the radar. We need to see more than just the main thread with UIWebView.
Our crash collection system does not send us Apple crash logs, so for automated cases we don't generally have them, just our own. I can provide more data from those (e.g., stacks of other threads) if that would help. We can try to repro again with the steps from comment 0 to get an Apple crash log that way, but don't you already have access to automated crash log collection in the format you are looking for (the data that feeds into the iTunes Connect crash dashboard)?
Moving to RESOLVED/INVALID because this issue was fixed outside of WebKit. Thank you for filing a radar about it as well.