I've just had a crash log from a customer's device, and it's crashing here:
dispatch_async(dispatch_get_global_queue(0, 0), ^{
JSContext *javaScriptContext = [[JSContext alloc] init];
Here's the crash log:
Thread 11 Crashed:
0 JavaScriptCore 0x31009cd6 WTFCrash + 54
1 JavaScriptCore 0x30e0edf6 WTF::OSAllocator::reserveAndCommit(unsigned long, WTF::OSAllocator::Usage, bool, bool, bool) + 166
2 JavaScriptCore 0x30e0ed2a WTF::OSAllocator::reserveUncommitted(unsigned long, WTF::OSAllocator::Usage, bool, bool, bool) + 14
3 JavaScriptCore 0x30e14736 JSC::JSStack::JSStack(JSC::VM&, unsigned long) + 74
4 JavaScriptCore 0x30e146d2 JSC::Interpreter::Interpreter(JSC::VM&) + 22
5 JavaScriptCore 0x30e10fb8 JSC::VM::VM(JSC::VM::VMType, JSC::HeapType) + 2516
6 JavaScriptCore 0x30fbf48e JSC::VM::createContextGroup(JSC::HeapType) + 22
7 JavaScriptCore 0x30fbdc86 JSContextGroupCreate + 14
8 JavaScriptCore 0x30fd209e -[JSVirtualMachine init] + 6
9 JavaScriptCore 0x30fbd122 -[JSContext init] + 46
10 <redacted>
11 libdispatch.dylib 0x3a776d78 _dispatch_call_block_and_release + 8
12 libdispatch.dylib 0x3a77dda0 _dispatch_root_queue_drain + 216
13 libdispatch.dylib 0x3a77df88 _dispatch_worker_thread2 + 52
14 libsystem_pthread.dylib 0x3a8b8dbc _pthread_wqthread + 296
15 libsystem_pthread.dylib 0x3a8b8c80 start_wqthread + 4
WTFCrash, indeed.
At that point, several of the other threads were busy with Javascript-related memory stuff:
Thread 10:
0 libsystem_kernel.dylib 0x3a83f970 _kernelrpc_mach_vm_deallocate_trap + 20
1 libsystem_kernel.dylib 0x3a83fc5a mach_vm_deallocate + 26
2 libsystem_kernel.dylib 0x3a83fc36 vm_deallocate + 14
3 JavaScriptCore 0x30e18f20 JSC::BlockAllocator::releaseFreeRegions() + 64
4 JavaScriptCore 0x30f89784 JSC::CopiedSpace::~CopiedSpace() + 20
5 JavaScriptCore 0x30faea28 JSC::Heap::~Heap() + 336
6 JavaScriptCore 0x30fbf434 JSC::VM::~VM() + 2600
7 JavaScriptCore 0x30e0bb82 JSC::JSLockHolder::~JSLockHolder() + 90
8 JavaScriptCore 0x30fbdcf8 JSContextGroupRelease + 76
9 JavaScriptCore 0x30fd21be -[JSVirtualMachine dealloc] + 22
10 libobjc.A.dylib 0x3a29eb06 objc_object::sidetable_release(bool) + 170
11 libobjc.A.dylib 0x3a290002 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 354
12 libdispatch.dylib 0x3a77de08 _dispatch_root_queue_drain + 320
13 libdispatch.dylib 0x3a77df88 _dispatch_worker_thread2 + 52
14 libsystem_pthread.dylib 0x3a8b8dbc _pthread_wqthread + 296
15 libsystem_pthread.dylib 0x3a8b8c80 start_wqthread + 4
Thread 15 name: JavaScriptCore::BlockFree
Thread 15:
0 libsystem_kernel.dylib 0x3a851f38 __psynch_cvwait + 24
1 libsystem_pthread.dylib 0x3a8ba224 _pthread_cond_wait + 536
2 libsystem_pthread.dylib 0x3a8bb040 pthread_cond_timedwait + 40
3 JavaScriptCore 0x30e12eb8 WTF::ThreadCondition::timedWait(WTF::Mutex&, double) + 104
4 JavaScriptCore 0x30e12ce4 JSC::BlockAllocator::blockFreeingThreadMain() + 88
5 JavaScriptCore 0x30e103a8 WTF::wtfThreadEntryPoint(void*) + 12
6 libsystem_pthread.dylib 0x3a8bac1a _pthread_body + 138
7 libsystem_pthread.dylib 0x3a8bab8a _pthread_start + 98
8 libsystem_pthread.dylib 0x3a8b8c8c thread_start + 4
Thread 16 name: JavaScriptCore::Marking
Thread 16:
0 libsystem_kernel.dylib 0x3a851f38 __psynch_cvwait + 24
1 libsystem_pthread.dylib 0x3a8ba224 _pthread_cond_wait + 536
2 libsystem_pthread.dylib 0x3a8bb000 pthread_cond_wait + 36
3 JavaScriptCore 0x30fae23e JSC::GCThread::waitForNextPhase() + 74
4 JavaScriptCore 0x30fae298 JSC::GCThread::gcThreadMain() + 48
5 JavaScriptCore 0x30e103a8 WTF::wtfThreadEntryPoint(void*) + 12
6 libsystem_pthread.dylib 0x3a8bac1a _pthread_body + 138
7 libsystem_pthread.dylib 0x3a8bab8a _pthread_start + 98
8 libsystem_pthread.dylib 0x3a8b8c8c thread_start + 4
Thread 17 name: JavaScriptCore::BlockFree
Thread 17:
0 libsystem_kernel.dylib 0x3a851f38 __psynch_cvwait + 24
1 libsystem_pthread.dylib 0x3a8ba224 _pthread_cond_wait + 536
2 libsystem_pthread.dylib 0x3a8bb040 pthread_cond_timedwait + 40
3 JavaScriptCore 0x30e12eb8 WTF::ThreadCondition::timedWait(WTF::Mutex&, double) + 104
4 JavaScriptCore 0x30e12ce4 JSC::BlockAllocator::blockFreeingThreadMain() + 88
5 JavaScriptCore 0x30e103a8 WTF::wtfThreadEntryPoint(void*) + 12
6 libsystem_pthread.dylib 0x3a8bac1a _pthread_body + 138
7 libsystem_pthread.dylib 0x3a8bab8a _pthread_start + 98
8 libsystem_pthread.dylib 0x3a8b8c8c thread_start + 4
So... what's the problem with creating a JSContext on a global queue? What should I do differently to avoid the problem?
Luckily it's open source!
void* OSAllocator::reserveAndCommit(size_t bytes, Usage usage, bool writable, bool executable, bool includesGuardPages)
tries to allocate a virtual machine, by allocating some memory
result = mmap(result, bytes, protection, flags, fd, 0);
if (result == MAP_FAILED) {
...
CRASH();
}
the memory allocation fails and the app crashes.
Sooooo my best guess would be that this issue is popping up, due to a low memory situation.
How many of these are you allocating?
I experienced a similar issue. Ultimately the extra JavaScriptCore::BlockFree threads were a symptom of the JSContext not getting released. I'd suggest checking to make sure your JSVirtualMachine and JSContext are getting released at the end of execution.
Also as an aside, I am now successfully creating many JSVirtualMachines (1000+ during a run) without any issue, so I don't think that there is a problem with this unless you need a lot of these to run concurrently (like 50+).
Hope that helps!
来源：https://stackoverflow.com/questions/21159798/should-i-avoid-creating-jscontexts-in-global-queues