Bug 227767 - fitcored crashes at JavaScriptCore: JSC::Heap::releaseAccessSlow
Summary: fitcored crashes at JavaScriptCore: JSC::Heap::releaseAccessSlow
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-07-07 13:22 PDT by Michael Saboff
Modified: 2021-07-07 14:55 PDT (History)
7 users (show)

See Also:


Attachments
Patch (3.39 KB, patch)
2021-07-07 13:34 PDT, Michael Saboff
ggaren: review+
msaboff: commit-queue?
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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>