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!
So, just to be clear, pas_reallocation_did_fail is a red herring. Look at the backtrace in your third-party crash report:
5 JavaScriptCore … pas_reallocation_did_fail + 195648
6 JavaScriptCore … pas_reallocation_did_fail + 180240
7 JavaScriptCore … pas_reallocation_did_fail + 181376
8 JavaScriptCore … pas_reallocation_did_fail + 180240
9 JavaScriptCore … pas_reallocation_did_fail + 187084
10 JavaScriptCore … pas_reallocation_did_fail + 186032
11 JavaScriptCore … pas_reallocation_did_fail + 187084
12 JavaScriptCore … pas_reallocation_did_fail + 186032
13 JavaScriptCore … pas_reallocation_did_fail + 186032
14 JavaScriptCore … pas_reallocation_did_fail + 180240
15 JavaScriptCore … pas_reallocation_did_fail + 186032
16 JavaScriptCore … pas_reallocation_did_fail + 187084
17 JavaScriptCore … pas_reallocation_did_fail + 7297626328
All of the symbol offsets are large, and one is ginormous. It’s very unlikely that pas_reallocation_did_fail is 7 GiB long! That indicates that your third-party crash reporter is not symbolicating properly.
Of course, JavaScriptCore JITs, which makes useful symbolication hard )-:
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
You are right to be sceptical about that.
Debugging a problem like this is going to be challenging. You’re going to need crash reports that you can trust. That means you can’t use a third-party crash reporter [1]. My advice is that you disable that crash reporter, ship a new version of your app, and wait to see what Apple crash reports you get [2].
Basically, every JS block is enqueued and then run by a dedicated thread specific to our JSContext.
That’s more restrictive than it needs to be, which is fine. See this doc page for more about this.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] For an in-depth explanation of why I don’t trust third-party crash reporters, see Implementing Your Own Crash Reporter.
[2] Note that the presence of the third-party crash reporter undermines the trustworthiness of the Apple crash reports, so there’s not much point trying to debug the issue using the Apple crash reports you currently have, regardless of whether they’re caused by the same underlying problem or not.