JavascriptCore crashes with pas_reallocation_did_fail

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!

Answered by DTS Engineer in 848399022

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.

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.

Thanks for the above answer.

I think my options here are very little then. My business relies a lot on Crashlytics, we can track bugs very easily and the alert system is a must for us.

Unfortunately, I can't just disable it :(. This is also happening randomly to any user, so I can't even disable it on a reduced audience.

Something we could do is to disable Crashlytics for a few seconds when app moves back to the foreground (when the crash is occurring), but I don't know if that disables Crashlytics completely to prevent Apple crash reports to get disrupted.

Maybe my next question would be: Is really Crashlytics the problem here or actually the fact that we have two tools bothering each other?

JavascriptCore crashes with pas_reallocation_did_fail
 
 
Q