Bug 185554 - iOS 11.3.1 Safari crashes repeatedly on Google Bulletin under vmEntryToJavaScript
Summary: iOS 11.3.1 Safari crashes repeatedly on Google Bulletin under vmEntryToJavaSc...
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: Safari 11
Hardware: Other iOS 11
: P2 Normal
Assignee: Michael Saboff
URL: https://posts.google.com/bulletin/app
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-05-11 11:14 PDT by Doug Parker
Modified: 2018-06-15 12:07 PDT (History)
8 users (show)

See Also:


Attachments
First WebContent crash report. (74.99 KB, text/plain)
2018-05-11 11:14 PDT, Doug Parker
no flags Details
Second WebContent crash report (76.83 KB, text/plain)
2018-05-11 11:14 PDT, Doug Parker
no flags Details
First stacks crash report (633.86 KB, text/plain)
2018-05-11 11:15 PDT, Doug Parker
no flags Details
Second stacks crash report (611.47 KB, text/plain)
2018-05-11 11:15 PDT, Doug Parker
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Doug Parker 2018-05-11 11:14:16 PDT
Created attachment 340205 [details]
First WebContent crash report.

Safari crashed with a "A problem repeatedly occurred at <URL>". This was on the Bulltin PWA at https://posts.google.com/bulletin/app.

This happened on page load, it crashed once with the banner and then reloaded the page and crashed immediately again saying "A problem repeatedly occurred at <URL>". Subsequent page loads worked correctly.

I extracted a couple WebContent crash reports from the exact time of the crash. There were also a couple stacks reports a few minutes prior. They may not be related but I figured I'd include them for completeness.
Comment 1 Doug Parker 2018-05-11 11:14:39 PDT
Created attachment 340206 [details]
Second WebContent crash report
Comment 2 Doug Parker 2018-05-11 11:15:07 PDT
Created attachment 340207 [details]
First stacks crash report
Comment 3 Doug Parker 2018-05-11 11:15:18 PDT
Created attachment 340208 [details]
Second stacks crash report
Comment 4 Chris Dumez 2018-05-11 11:41:01 PDT
Thread 0 Crashed:
0   JavaScriptCore                	0x0000000187fa3f3c llint_entry + 18684
1   ???                           	0x0000000c28387164 0 + 52214395236
2   JavaScriptCore                	0x0000000187fa6728 llint_entry + 28904
3   ???                           	0x0000000c283f7c4c 0 + 52214856780
4   JavaScriptCore                	0x0000000187f9f470 vmEntryToJavaScript + 272
5   JavaScriptCore                	0x0000000188550a74 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 184 (./jit/JITCode.cpp:81)
6   JavaScriptCore                	0x0000000187ea840c JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 464 (./interpreter/Interpreter.cpp:1028)
7   JavaScriptCore                	0x0000000188673540 JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 168 (./runtime/CallData.cpp:41)
8   JavaScriptCore                	0x00000001887269f8 JSC::JSJobMicrotask::run(JSC::ExecState*) + 488 (./runtime/JSJob.cpp:81)
9   WebCore                       	0x0000000189e4e700 WebCore::JSDOMWindowMicrotaskCallback::call() + 152 (Sources/WebCore/WebCore-7605.1.33.0.3/bindings/js/JSMainThreadExecState.h:90)
10  WebCore                       	0x000000018a02da08 WebCore::ActiveDOMCallbackMicrotask::run() + 72 (/usr/local/include/wtf/Function.h:56)
11  WebCore                       	0x000000018a09797c WebCore::MicrotaskQueue::performMicrotaskCheckpoint() + 108 (Sources/WebCore/WebCore-7605.1.33.0.3/dom/Microtasks.cpp:83)
12  WebCore                       	0x0000000189e5e51c WebCore::JSMainThreadExecState::didLeaveScriptContext(JSC::ExecState*) + 24 (Sources/WebCore/WebCore-7605.1.33.0.3/bindings/js/JSMainThreadExecState.cpp:40)
13  WebCore                       	0x0000000189e50564 WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext&, WebCore::Event&) + 1208 (Sources/WebCore/WebCore-7605.1.33.0.3/bindings/js/JSMainThreadExecState.h:145)
14  WebCore                       	0x000000018a08cbe0 WebCore::EventTarget::fireEventListeners(WebCore::Event&, WTF::Vector<WTF::RefPtr<WebCore::RegisteredEventListener, WTF::DumbPtrTraits<WebCore::RegisteredEventListener> >, 1ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>) + 760 (Sources/WebCore/WebCore-7605.1.33.0.3/dom/EventTarget.cpp:289)
15  WebCore                       	0x000000018a088798 WebCore::EventTarget::fireEventListeners(WebCore::Event&) + 596 (Sources/WebCore/WebCore-7605.1.33.0.3/dom/EventTarget.cpp:231)
16  WebCore                       	0x000000018a088534 WebCore::EventContext::handleLocalEvents(WebCore::Event&) const + 136 (Sources/WebCore/WebCore-7605.1.33.0.3/dom/EventContext.cpp:56)
17  WebCore                       	0x000000018a089a24 WebCore::dispatchEventInDOM(WebCore::Event&, WebCore::EventPath const&) + 164 (Sources/WebCore/WebCore-7605.1.33.0.3/dom/EventDispatcher.cpp:91)
18  WebCore                       	0x000000018a089b4c WebCore::EventDispatcher::dispatchEvent(WTF::Vector<WebCore::EventTarget*, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc> const&, WebCore::Event&) + 124 (Sources/WebCore/WebCore-7605.1.33.0.3/dom/EventDispatcher.cpp:186)
19  WebCore                       	0x0000000189ce6b34 WebCore::IDBRequest::dispatchEvent(WebCore::Event&) + 312 (Sources/WebCore/WebCore-7605.1.33.0.3/Modules/indexeddb/IDBRequest.cpp:325)
20  WebCore                       	0x00000001894fd620 WebCore::DocumentEventQueue::pendingEventTimerFired() + 260 (Sources/WebCore/WebCore-7605.1.33.0.3/dom/DocumentEventQueue.cpp:151)
21  WebCore                       	0x0000000189423fc0 WebCore::ThreadTimers::sharedTimerFiredInternal() + 352 (Sources/WebCore/WebCore-7605.1.33.0.3/platform/ThreadTimers.cpp:118)
22  WebCore                       	0x0000000189423e4c WebCore::timerFired(__CFRunLoopTimer*, void*) + 28 (Sources/WebCore/WebCore-7605.1.33.0.3/platform/cf/MainThreadSharedTimerCF.cpp:74)
23  CoreFoundation                	0x00000001812abaa8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28 (Sources/CoreFoundation/Foundation-1452.23/CoreFoundation/RunLoop.subproj/CFRunLoop.c:1832)
24  CoreFoundation                	0x00000001812ab76c __CFRunLoopDoTimer + 864 (Sources/CoreFoundation/Foundation-1452.23/CoreFoundation/RunLoop.subproj/CFRunLoop.c:2415)
25  CoreFoundation                	0x00000001812ab010 __CFRunLoopDoTimers + 248 (Sources/CoreFoundation/Foundation-1452.23/CoreFoundation/RunLoop.subproj/CFRunLoop.c:2562)
26  CoreFoundation                	0x00000001812a8b60 __CFRunLoopRun + 2168 (Sources/CoreFoundation/Foundation-1452.23/CoreFoundation/RunLoop.subproj/CFRunLoop.c:0)
27  CoreFoundation                	0x00000001811c8da8 CFRunLoopRunSpecific + 552 (Sources/CoreFoundation/Foundation-1452.23/CoreFoundation/RunLoop.subproj/CFRunLoop.c:3245)
28  Foundation                    	0x0000000181c3d674 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 304 (Sources/Foundation/Foundation-1452.23/Foundation/Soil.subproj/NSRunLoop.m:367)
29  Foundation                    	0x0000000181cb21a8 -[NSRunLoop(NSRunLoop) run] + 88 (Sources/Foundation/Foundation-1452.23/Foundation/Soil.subproj/NSRunLoop.m:389)
30  libxpc.dylib                  	0x0000000180f71b54 _xpc_objc_main + 516 (libxpc/libxpc-1205.50.76/src/main.m:167)
31  libxpc.dylib                  	0x0000000180f73c28 xpc_main + 180 (libxpc/libxpc-1205.50.76/src/init.c:1476)
32  com.apple.WebKit.WebContent   	0x000000010052f5ac main + 380 (Sources/WebKit2/WebKit2-7605.1.33.0.3/Shared/EntryPointUtilities/mac/XPCService/XPCServiceMain.mm:148)
33  libdyld.dylib                 	0x0000000180c59fc0 start + 4
Comment 5 Chris Dumez 2018-05-11 11:42:05 PDT
Could be related to https://bugs.webkit.org/show_bug.cgi?id=185231.
Comment 6 Radar WebKit Bug Importer 2018-05-11 11:42:41 PDT
<rdar://problem/40169813>
Comment 7 Maciej Stachowiak 2018-05-11 14:12:15 PDT
This looks like a crash in JIT-generated code.
Comment 8 Michael Saboff 2018-05-18 09:34:30 PDT
This is actually a crash in the LLInt.

I cannot reproduce this with the latest build, although it says that my "Account not authorized for Bulletin".  I requested access.
Comment 9 Michael Saboff 2018-05-18 10:13:55 PDT
I was granted access to Bulletin.  I still can't reproduce the crash.  I tried navigating around, logging out and back in, and killing and restarting Safari.  I'll try a little more.  Next I'll look at what bytecode / instruction we crashed on in the interpreter.
Comment 10 Michael Saboff 2018-05-18 10:33:27 PDT
I tried reproducing on an iPhone X and an original iPad Pro and did not get the crash.  The iPhone X is running an 11.4 seed.  The iPad Pro is running 11.3.1, the exact same build reported for this crash.
Comment 11 Michael Saboff 2018-05-18 14:25:22 PDT
Looking at the crash reports and the interpreter assembly language, and it appears we are crashing executing the resolve_scope bytecode.  We are crashing accessing the next pointer of a scope chain (linked list of JSScope object) using a pointer value of 1, found in x0.  The "m_next" field is located at offset 24 (0x18), thus the crash trying to access memory at 0x19.  This is for a closure variable.

There isn't enough information in the crash log to determine if the head of the scope chain in the stack is bad or somewhere down the chain.  It appears that we are in the process of loading the last JSScope object in the list according to the scope depth of 1 in x2.

Here is the LLInt code in question with the crashing instruction highlighted:

macro resolveScope()
    loadisFromInstruction(5, t2)
    loadisFromInstruction(2, t0)
    loadp [cfr, t0, 8], t0
    btiz t2, .resolveScopeLoopEnd

.resolveScopeLoop:
    loadp JSScope::m_next[t0], t0
    subi 1, t2
    btinz t2, .resolveScopeLoop

.resolveScopeLoopEnd:
    loadisFromInstruction(1, t1)
    storeq t0, [cfr, t1, 8]
end


_llint_op_resolve_scope:
    traceExecution()
    loadisFromInstruction(4, t0)

#rGlobalProperty:
    bineq t0, GlobalProperty, .rGlobalVar
    getConstantScope(1)
    dispatch(constexpr op_resolve_scope_length)

.rGlobalVar:
    bineq t0, GlobalVar, .rGlobalLexicalVar
    getConstantScope(1)
    dispatch(constexpr op_resolve_scope_length)

.rGlobalLexicalVar:
    bineq t0, GlobalLexicalVar, .rClosureVar
    getConstantScope(1)
    dispatch(constexpr op_resolve_scope_length)

.rClosureVar:
    bineq t0, ClosureVar, .rModuleVar
    resolveScope()
    # Expands to:
            loadisFromInstruction(5, t2)
            loadisFromInstruction(2, t0)
            loadp [cfr, t0, 8], t0
            btiz t2, .resolveScopeLoopEnd

        .resolveScopeLoop:
>> CRASH << loadp JSScope::m_next[t0], t0  # crashing here, t0 (x0) contains 0x1
            subi 1, t2                     # current scope depth (x2) contains 1
            btinz t2, .resolveScopeLoop

        .resolveScopeLoopEnd:
            loadisFromInstruction(1, t1)
            storeq t0, [cfr, t1, 8]

    dispatch(constexpr op_resolve_scope_length)

.rModuleVar:
    bineq t0, ModuleVar, .rGlobalPropertyWithVarInjectionChecks
    getConstantScope(1)
    dispatch(constexpr op_resolve_scope_length)
Comment 12 Michael Saboff 2018-06-15 12:07:01 PDT
I sent an email to the submitter asking if they have seen any more occurrences of this.  Here is the reply:

Hi Michael,

Thanks for reaching out, glad to see that these issues are being investigated. I've seen this issue specifically on an iPod Touch 6 running various 11.3.X versions, though our QA tester and one of our PMs have seen this issue as well on other devices. It tended to reproduce on page load, immediately crashing, reloading, and then crashing again.

I personally haven't seen this recently, though I've been working on non-iOS stuff lately so I haven't been using it day-to-day. I asked our QA tester about this and she hasn't seen it recently either. We've been making performance improvements to the app over the last few weeks which may or may not be related to the change. I wish I had a directly reproducible case, but unfortunately it's just not one of those bugs. If we do see it again, I'll definitely pull the crash report and post it to the WebKit bug in case that helps.

Doug

----
Closing this out as configuration changed.