我應該避免在全局隊列中創建JSContext嗎？

我剛剛從客戶的設備崩潰日誌，它的崩潰在這裏：我應該避免在全局隊列中創建JSContext嗎？

dispatch_async(dispatch_get_global_queue(0, 0), ^{ 

    JSContext *javaScriptContext = [[JSContext alloc] init];

這裏的崩潰日誌：

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，確實如此。

在這一點上，其他幾個線程都在忙於JavaScript相關記憶的東西：

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

所以...什麼是對一個全球性的隊列生成一個JSContext問題？我應該怎樣做才能避免這個問題？

來源

2014-01-16 Simon

我實際上建議你應該避免創建如此多的獨特的JSContexts，如果你可以幫助它的話。相反，您應該嘗試利用單個JSContext（如果可能！），而不是每次創建全新的JSContext。是否可以利用單個JSContext進行隊列執行，而不是使用每個隊列項目創建新的JSContext？ –

但是，這也只是一個天真的聲明，沒有真正知道爲什麼你需要爲每個隊列項目創建一個新的JSContext的原因的根源。如果您想更多地瞭解重複使用現有的JSContext來處理多種事情，我可以嘗試提供幫助！ –

幸運的是它是開源的！

http://www.opensource.apple.com/source/JavaScriptCore/JavaScriptCore-7534.57.3/wtf/OSAllocatorPosix.cpp

void* OSAllocator::reserveAndCommit(size_t bytes, Usage usage, bool writable, bool executable, bool includesGuardPages)

嘗試分配一個虛擬機，通過分配一些存儲器

result = mmap(result, bytes, protection, flags, fd, 0); 
    if (result == MAP_FAILED) { 
     ... 
      CRASH(); 
    }

存儲器分配失敗和應用程序崩潰。

Sooooo我最好的猜測是，這個問題會彈出，由於內存不足的情況。

你分配了多少？

來源

2014-01-20 18:00:23 Andrew

它應該只是一次一個;假設我認爲他們沒有被清理掉，那麼碰撞發生時應該會有十到二十個人創建。它只發生在客戶的32位設備上;也許它與此有關？ http://stackoverflow.com/questions/17921652/cocoa-mac-javascript-core-crash-on-the-38th-call – Simon

它也發生在iPhone 5上嗎？ 4S有一半的內存，所以它可能是操作系統只是內存不足，如果它發生在iPhone5上，這可能是32位的問題。 – Andrew

我會試着追查一個5進行測試。如果它*是32位問題，我該怎麼辦？ – Simon

我遇到過類似的問題。最終，額外的JavaScriptCore :: BlockFree線程是未發佈的JSContext的症狀。我建議檢查一下，以確保在執行結束時釋放JSVirtualMachine和JSContext。除此之外，我現在已經成功地創建了許多JSVirtualMachines（運行期間的1000+），沒有任何問題，所以我不認爲這有什麼問題，除非你需要很多這些同時運行（如50+）。

希望有幫助！

來源

2014-02-23 22:23:59

我應該避免在全局隊列中創建JSContext嗎？

回答

相關問題