I have a transformation function that takes in data, executes some instructions, and returns an output. This function is dynamic and not shipped with the binary. Currently, I’m executing it using JavaScriptCore.JSContext, which works well, but the function itself is written in JavaScript. Is there a way to achieve something similar using Swift – such as executing a dynamic Swift script, either directly or through other means? I know this is possible on macOS, but I’m not sure about iOS. I’ve also heard that extensions might open up some possibilities here. Any insights or alternative approaches would be appreciated.

Hi there, I'm experiencing several crashes on JavaScriptCore pas_panic_on_out_of_memory_error, only on devices with tvOS 15.4 and 15.4.1. This happens with users using the app for several hours as well as 5 seconds after launching the app. Devices: AppleTV6,2 and AppleTV5,3 Thread 14 — JavaScriptCore pas_panic_on_out_of_memory_error (JavaScriptCore) JavaScriptCore bmalloc_try_iso_allocate_impl_impl_slow (JavaScriptCore) JavaScriptCore bmalloc_heap_config_specialized_local_allocator_try_allocate_small_segregated_slow (JavaScriptCore) JavaScriptCore bmalloc_allocate_impl_casual_case (JavaScriptCore) JavaScriptCore ***::String::String(char16_t const*, unsigned int) (JavaScriptCore) JavaScriptCore JSC::LiteralParser<char16_t>::parsePrimitiveValue(JSC::VM&) (JavaScriptCore) JavaScriptCore JSC::LiteralParser<char16_t>::parse(JSC::ParserState) (JavaScriptCore) JavaScriptCore JSC::jsonProtoFuncParse(JSC::JSGlobalObject*, JSC::CallFrame*) (JavaScriptCore) JavaScriptCore llint_entry (JavaScriptCore) JavaScriptCore llint_entry (JavaScriptCore) JavaScriptCore llint_entry (JavaScriptCore) JavaScriptCore llint_entry (JavaScriptCore) JavaScriptCore vmEntryToJavaScript (JavaScriptCore) JavaScriptCore JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (JavaScriptCore) JavaScriptCore JSC::boundThisNoArgsFunctionCall(JSC::JSGlobalObject*, JSC::CallFrame*) (JavaScriptCore) JavaScriptCore vmEntryToNative (JavaScriptCore) JavaScriptCore JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (JavaScriptCore) JavaScriptCore JSC::profiledCall(JSC::JSGlobalObject*, JSC::ProfilingReason, JSC::JSValue, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (JavaScriptCore) JavaScriptCore JSObjectCallAsFunction (JavaScriptCore) JavaScriptCore -[JSValue invokeMethod:withArguments:] (JavaScriptCore) ITMLKit -[IKJSObject invokeMethod:withArguments:] (ITMLKit) ITMLKit -[IKJSEventListenerObject invokeMethod:withArguments:thenDispatchEvent:extraInfo:] (ITMLKit) ITMLKit __43-[IKJSXMLHTTPRequest setRequestReadyState:]_block_invoke (ITMLKit) ITMLKit -[IKAppContext _doEvaluate:] (ITMLKit) ITMLKit -[IKAppContext _evaluate:] (ITMLKit) ITMLKit __41-[IKAppContext evaluate:completionBlock:]_block_invoke (ITMLKit) ITMLKit -[IKAppContext _sourcePerform] (ITMLKit) ITMLKit -[IKConcurrentEvaluator lockSchedulingForEvaluation:] (ITMLKit) ITMLKit IKRunLoopSourcePerformCallBack (ITMLKit) CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (CoreFoundation) CoreFoundation __CFRunLoopDoSource0 (CoreFoundation) CoreFoundation __CFRunLoopDoSources0 (CoreFoundation) CoreFoundation __CFRunLoopRun (CoreFoundation) CoreFoundation CFRunLoopRunSpecific (CoreFoundation) ITMLKit -[IKAppContext _jsThreadMain] (ITMLKit) Foundation __NSThread__start__ (Foundation) libsyste...ad.dylib _pthread_start (libsystem_pthread.dylib) libsyste...ad.dylib thread_start (libsystem_pthread.dylib) This issue seems very similar to this existing thread, although not sure its related

Hi, My app is using JavascriptCore to run the business logic in a javascript environment. We are randomly seeing crashes when users move the app back to the foreground. These crashes are reported by Firebase (I am attaching an example). I also tried to find them in Organizer, but the stacktraces don't match and I am not sure if they are pointing to the same error (I attach one just in case). I was trying to investigate a little bit about this, but I could find any explanation about what pas_reallocation_did_fail would mean. Here is our implementation: -(void) enqueueCallback:(JSValue *)callback withArguments:(NSArray *)args exclusive:(BOOL)exclusive { [self enqueueBlock:^{ @autoreleasepool { [callback callWithArguments:args]; } } exclusive:exclusive]; } Basically, every JS block is enqueued and then run by a dedicated thread specific to our JSContext. Can I get some help? Thanks in advance! Crashlytics.txt 2024-08-30_10-00-01.2572_-0400-f757f8306eda9679ec1b2ff90fbc66c4eb1fbee7.crash

My app started crashing since iOS 18.4 update. Crashes started happening in 18.4 beta and are still happening in the official 18.4 RTM build (22E240). Crash is happening randomly and I cannot reproduce it, but it affects a few percent of users. As you can see in log, crash happen when NSAttributedString is loading HTML with init(data:options:documentAttributes:) with .html documentType. Crash-2025-04-02-154720.ips

Hello, my application experiences crashes related to JavaScriptCore in iOS 17 and 18. I would like to consult about potential causes, to determine whether it is a bug in JavaScriptCore or an issue with my code implementation. First, the crash stack always includes the call to JSC::MarkedBlock::aboutToMarkSlow(unsigned int). In the iOS 17 version, the crash occurs on this line, typically JSC::MarkedBlock::aboutToMarkSlow(unsigned int) + 88. In iOS 18 and later, the stack crashes atJSC::MarkedBlock::dumpInfoAndCrashForInvalidHandle(WTF::AbstractLocker&, JSC::HeapCell*). I checked the source code of JavaScriptCore for both iOS 17.6 and iOS 18.2 and observed modifications in the implementation of aboutToMarkSlow. My question is under what circumstances could this crash occur? crash.log I have attached a crash log encountered in iOS 18, hoping you can provide more effective information for problem diagnosis, especially since there are specific details worth noting near the crash registers. INVALID HANDLE: MarkedBlock = 0x141158000; heapCell = 0x14115bfa0; type = 0 INVALID HANDLE: found 24 0s at beginning of block INVALID HANDLE: block in another VM: 1, block in another VM: 1; other VM is 0x1324b6000 Moreover, in iOS 18.4, due to the implementation of dumpInfoAndCrashForInvalidHandleV2, the message has changed to: INVALID HANDLE 587: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=0; totalzeros=0; blockVM=0x0; actualVM=0x0; isBlockVMValid=0; isBlockInSet=0; isBlockInDir=0; foundInBlockVM=0; INVALID HANDLE 606: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=16384; totalZeros=16384; blockVM=0x0; actualVM=0x0; isBlockVMValid=0; isBlockInSet=0; isBlockInDir=0; foundInBlockVM=0; INVALID HANDLE 615: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=16384; totalZeros=16384; blockVM=0x0; actualVM=0x0; isBlockVMValid=0; isBlockInSet=1; isBlockInDir=1; foundInBlockVM=0; (Further INVALID HANDLE messages follow the same format) I hope this provides you with more information.

Hello, We're developing an SDK for iOS and need clarification on Apple's policies regarding the use of JavaScriptCore. Specifically, we want to understand if it's permissible to execute JavaScript code provided by our customers using JavaScriptCore. Our use case is as follows: Our customers will supply JavaScript code snippets, which our SDK will receive as text. The intention is to run these code snippets via JavaScriptCore to present interactive guides or dynamic content to the end-users of the app. Would executing customer-provided JavaScript code in this manner be considered a violation of Apple's App Store guidelines?

After the app is put in background for sometime and the app crashes, Some cases have the webView involvement before putting the app in to background for quite sometime and pulled into foreground. Here's the crash log information. Identifier: com.app.myapp Version: 2.3.3 (30) AppStoreTools: 16C5031b AppVariant: 1:iPhone9,1:15 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.app.myapp [2833] Date/Time: 2024-12-12 17:30:57.4489 +0100 Launch Time: 2024-12-12 17:04:19.7290 +0100 OS Version: iPhone OS 15.5 (19F77) Release Type: User Baseband Version: 9.61.00 Report Version: 104 **Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x000000018f1358e0 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: SIGNAL 5 Trace/BPT trap: 5 Terminating Process: exc handler [82527] Triggered by Thread: 10 Kernel Triage: VM - Fault hit memory shortage** Thread 10 Crashed: 0 WebKit 0x000000018f1358e0 WTFCrashWithInfo(int, char const*, char const*, int) + 20 (Assertions.h:732) 1 WebKit 0x000000018f72e348 WebKit::allDataStores() + 72 (WebsiteDataStore.cpp:100) 2 WebKit 0x000000018f72e278 WebKit::WebsiteDataStore::forEachWebsiteDataStore(WTF::Function<void (WebKit::WebsiteDataStore&)>&&) + 24 (WebsiteDataStore.cpp:107) 3 WebKit 0x000000018f67c440 WebKit::WebProcessPool::updateProcessAssertions() + 52 (WebProcessPool.cpp:1773) 4 WebKit 0x000000018f684508 WebKit::WebProcessProxy::didSetAssertionType(WebKit::ProcessAssertionType) + 880 (Function.h:82) 5 WebKit 0x000000018f5bfdd0 WebKit::ProcessThrottler::setAssertionType(WebKit::ProcessAssertionType) + 712 (ProcessThrottler.cpp:148) 6 WebKit 0x000000018f5bf9b4 WebKit::ProcessThrottler::updateAssertionIfNeeded() + 408 (ProcessThrottler.cpp:176) 7 WebKit 0x000000018f5c42b0 WebKit::ProcessThrottler::Activity<(WebKit::ProcessThrottler::ActivityType)1>::Activity(WebKit::ProcessThrottler&, WTF::ASCIILiteral) + 76 (ProcessThrottler.cpp:58) 8 WebKit 0x000000018f659958 WebKit::WebPageProxy::runJavaScriptInFrameInScriptWorld(WebCore::RunJavaScriptParameters&&, std::__1::optional<WTF::ObjectIdentifierWebCore::FrameIdentifierType >, API::ContentWorld&, WTF::Comple... + 240 (ProcessThrottler.h:66) 9 WebKit 0x000000018f3ca7cc -[WKWebView _evaluateJavaScript:asAsyncFunction:withSourceURL:withArguments:forceUserGesture:inFrame:inWorld:completionHandler:] + 1352 (WKWebView.mm:1151) 10 WebKit 0x000000018f131700 -[WKWebView evaluateJavaScript:completionHandler:] + 120 (WKWebView.mm:896) 11 MyApp 0x00000001044e7e64 cli_signalHandler + 2420 12 MyApp 0x00000001044e4470 getExtraInfoId + 132792 13 MyApp 0x00000001044c2b18 CLI_Reset + 50684 14 MyApp 0x00000001044c2a18 CLI_Reset + 50428 15 MyApp 0x00000001044c1cec CLI_Reset + 47056 16 MyApp 0x00000001044c27e8 CLI_Reset + 49868 17 MyApp 0x00000001044e01f4 getExtraInfoId + 115772 18 MyApp 0x0000000104492498 StringToScreenDensityLevel + 4588 19 libdispatch.dylib 0x0000000180e80094 _dispatch_client_callout + 16 (object.m:560) 20 libdispatch.dylib 0x0000000180e22bb8 _dispatch_continuation_pop$VARIANT$mp + 440 (inline_internal.h:2622) 21 libdispatch.dylib 0x0000000180e348dc _dispatch_source_invoke$VARIANT$mp + 1668 (source.c:596) 22 libdispatch.dylib 0x0000000180e22730 _dispatch_queue_override_invoke + 424 (queue.c:0) 23 libdispatch.dylib 0x0000000180e2fb94 _dispatch_root_queue_drain + 340 (inline_internal.h:0) 24 libdispatch.dylib 0x0000000180e3039c _dispatch_worker_thread2 + 172 (queue.c:6935) 25 libsystem_pthread.dylib 0x00000001dc483dd4 _pthread_wqthread + 224 (pthread.c:2612) 26 libsystem_pthread.dylib 0x00000001dc48393c start_wqthread + 8 (:-1) Thread 10 crashed with ARM Thread State (64-bit): x0: 0x0000000000000064 x1: 0x000000018fad60a0 x2: 0x000000018fad6189 x3: 0x0000000000000113 x4: 0x0000000000000030 x5: 0x0000000100000030 x6: 0x0000000000000000 x7: 0x0000000000000001 x8: 0x000000016fd6b000 x9: 0x0000000106dd4580 x10: 0x000000000000002c x11: 0x0000000000020408 x12: 0x0000000000080000 x13: 0x0000000000000000 x14: 0x0000020000011000 x15: 0x0000000100000000 x16: 0x00000001dc48425c x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000016fd6a418 x20: 0x0000000282ece080 x21: 0x00000002834ac2a0 x22: 0x00000001f694c000 x23: 0x0000000117004a80 x24: 0x0000000283bb6558 x25: 0x000000011a00a1d8 x26: 0x0000000000000000 x27: 0x0000000000000002 x28: 0x000000016fd6b180 fp: 0x000000016fd6a3d0 lr: 0x000000018f72e348 sp: 0x000000016fd6a3b0 pc: 0x000000018f1358e0 cpsr: 0x60000000 esr: 0xf200c471 (Breakpoint) pointer authentication trap IB

Hello, I’m encountering a problem with WebSocket connections in Safari on iOS 18.1 and later when initiated from an iframe. The same implementation works perfectly in other browsers like Chrome but fails in Safari. In Safari, the WebSocket connection fails with error message "WebSocket connection to 'wss://MY_CONNECTION_URL' failed: The internet connection appears to be offline." Has anyone else faced this? Is this a known limitation or bug in Safari? Any workarounds or solutions would be greatly appreciated. Thank you!

It's being a very long time that I discovery that in some web pages, that use function requestAnimationFrame will cause a lot of cpu, but very little in Chrome. I have already submitted this bug nearly two years ago without printout requestAnimationFrame, no one replied. I submitted again and mention requestAnimationFrame recently, hope there will be some response. If anyone interested in this issue and know some tech in javascript please help. You can enter https://www.baidu.com/ and click one of the topic in all the 百度热搜 which have 弹幕滚动(using requestAnimationFrame, and cause a lot of cpu usage) on right.

crash screenshot below：

JavascriptCore doesn't come with any support for setTimeout (which is an API on the window/DOM object not provide din JavaScriptCore). So you need to implement a version of this yourself - no worries on that (there are examples to refer to out there, so it is fairly easy to set this up). But I have come across an issue with this that I am not sure how to handle properly. It relates to when the timer callback fires and runs code in the JavaScript engine itself. Consider this code snippet (assume I have provided an implementation of setTimeout): console.log('Hello - here we go'); setTimeout(() => { console.log('Hi from setTimeout callback ...'); }, 0); Promise.resolve().then(() => { console.log('Hi from promise'); }); console.log('Hi from main block'); In Node.js or say Safari, I would see this output: Hello - here we go Hi from main block Hi from promise Hi from setTimeout callback ... So the promise then() is handled before the settimeout callback is handled. I think this is basically because Promise then() handlers are pushed onto something like a microtask queue, and the setttimeout callbacks on a separate queue, and the microtask queue is emptied before any other queue is processed (after completing the current event loop of course). But when I implement this in JavaScript core, I don't always see the above - instead I can have: Hello - here we go Hi from main block Hi from setTimeout callback ... Hi from promise So the timeout callback can be run BEFORE the promise handler. This obviously is different from Node or Safari. Now I assume that is because the timeout callback is triggered from Swift native code that uses the call() API on a JSValue object that is provided when the settimeout is given to the native layer to process. And it seems that when native code attempts to execute JavaScript code (via call() or similar) then this is just executed as soon as possible - obviously not interrupting the Javascript core when executing any current event loop code, but potentially running between the point when the Javascript core finishes a normal event loop cycle and then starts processing the queued promise handlers. This means that code that runs nicely in Node (for example) might not work the same way due to this behaviour. Also, I also notice another thing: if JavaScript code makes a call to a native-provided method (e.g. by calling the setTimeout I show above, which I implement via a native-side handler) then during that call from JavaScript, it is possible for the native side to execute a call() and run Javascript code it wants. Again this is not what would happen in Node or Safari: it is not possible for timeouts (or network completions) to interrupt any 'builtin' function call, but in JavascriptCore it certainly is (to get around this I set a flag on the JavaScript side indicating a native call is being made, and if any native-triggered callback occurs on the javascript side when this flag is set, I have to 'queue' it via a promise handler for execution AFTER the current event loop is complete). Are these known issues with Javascript core and are there ways to get around them? thanks

After the release of iOS17, our app has collected JavaScriptCore crashes, and the crash has recently appeared in iOS17 and above. The number of crashes collected recently is increasing. The following are several complete crash log information. Currently, crashes are only collected on iOS17 and above systems. 2024-05-08_20-45-00.5216_+0800-fdb980f66f56d73b944ccc3466922d7fd0690089.crash 2024-05-11_02-42-46.0303_+0800-5ea1f23ba38c4782b80bd6304a9625e305c296a2.crash 2024-05-13_14-30-03.2084_+0800-d9598b08a153f5214b51257400423d4079049578.crash