Bug 227767

Summary: fitcored crashes at JavaScriptCore: JSC::Heap::releaseAccessSlow
Product: WebKit Reporter: Michael Saboff <msaboff>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ews-watchlist, ggaren, keith_miller, mark.lam, saam, tzagallo, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch ggaren: review+

Description Michael Saboff 2021-07-07 13:22:58 PDT
We are getting crash reports from fitcored like:

 JavaScriptCore: WTFCrashWithInfo(int, char const*, char const*, int)
 JavaScriptCore: JSC::Heap::releaseAccessSlow() <==
 JavaScriptCore: JSC::JITWorklist::waitUntilAllPlansForVMAreReady(JSC::VM&)
 JavaScriptCore: JSC::JITWorklist::cancelAllPlansForVM(JSC::VM&)
 JavaScriptCore: JSC::VM::~VM()
 JavaScriptCore: JSC::JSLock::willReleaseLock()
 JavaScriptCore: JSC::JSLock::unlock()
 JavaScriptCore: JSC::JSRunLoopTimer::timerDidFire()
 JavaScriptCore: JSC::JSRunLoopTimer::Manager::timerDidFire()
 JavaScriptCore: WTF::RunLoop::TimerBase::start(WTF::Seconds, bool)::$_1::__invoke(__CFRunLoopTimer*, void*)
 CoreFoundation: __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
 CoreFoundation: __CFRunLoopDoTimer
 CoreFoundation: __CFRunLoopDoTimers
 CoreFoundation: __CFRunLoopRun
 CoreFoundation: CFRunLoopRunSpecific
 Foundation: -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
 Foundation: -[NSRunLoop(NSRunLoop) run]
 SeymourServices: static DaemonProtocol.main()
 fitcored: main
 dyld: 

Although I am unable to reproduce the crash, the theory is that the heap access lock is being dropped in JSLock::willReleaseLock() so when we try unlocking it again in JITWorklist::waitUntilAllPlansForVMAreReady() via ReleaseHeapAccessScope, we fault.  This path can happen when the main thread becomes the sole reference to the VM during processing a request like the timer in this stack trace.  I suspect it is a race with other threads that are done using the VM.
Comment 1 Michael Saboff 2021-07-07 13:23:04 PDT
<rdar://78758218>
Comment 2 Radar WebKit Bug Importer 2021-07-07 13:23:22 PDT
<rdar://problem/80286291>
Comment 3 Michael Saboff 2021-07-07 13:34:32 PDT
Created attachment 433066 [details]
Patch
Comment 4 Geoffrey Garen 2021-07-07 13:41:05 PDT
Comment on attachment 433066 [details]
Patch

r=me

Is it ever correct to have heap access when we run the VM destructor? I think it is not. So, I think the VM destructor should RELEASE_ASSERT !hasAccess().

(I'm asking because that RELEASE_ASSERT would remove all the speculation in your reasoning.)
Comment 5 Michael Saboff 2021-07-07 14:44:05 PDT
(In reply to Geoffrey Garen from comment #4)
> Comment on attachment 433066 [details]
> Patch
> 
> r=me
> 
> Is it ever correct to have heap access when we run the VM destructor? I
> think it is not. So, I think the VM destructor should RELEASE_ASSERT
> !hasAccess().

You can have heap access when you destruct the VM, so such a RELEASE_ASSERT is not valid.
 
> (I'm asking because that RELEASE_ASSERT would remove all the speculation in
> your reasoning.)
Comment 6 Michael Saboff 2021-07-07 14:55:30 PDT
Committed r279677 (239482@main): <https://commits.webkit.org/239482@main>