Bug 84648 - Failure to allocate ArrayStorage in emit_op_new_array leads to poisonous JSArray
Summary: Failure to allocate ArrayStorage in emit_op_new_array leads to poisonous JSArray
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mark Hahnenberg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-23 16:29 PDT by Mark Hahnenberg
Modified: 2012-05-10 10:20 PDT (History)
3 users (show)

See Also:


Attachments
Patch (2.99 KB, patch)
2012-04-23 20:19 PDT, Mark Hahnenberg
no flags Details | Formatted Diff | Diff
Bencher results (14.00 KB, text/plain)
2012-04-24 09:52 PDT, Mark Hahnenberg
no flags Details
Patch (8.18 KB, patch)
2012-04-24 11:18 PDT, Mark Hahnenberg
no flags Details | Formatted Diff | Diff
Patch (28.66 KB, patch)
2012-05-10 10:04 PDT, Rafael Weinstein
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hahnenberg 2012-04-23 16:29:51 PDT
When emit_op_new_array successfully allocates a new JSArray but fails to allocate the corresponding ArrayStorage for it, it falls back to the out-of-line stub call to constructArray, which constructs and entirely new JSArray/ArrayStorage pair. This leaves us with a JSArray hanging around on the stack or in a register that did not go through its own constructor, thus giving it uninitialized memory in the two fields that are checked in JSArray::visitChildren.

The fix for this is to detect when we have successfully allocated a JSArray but failed to allocate its backing store and to write zeros into the correct places in the object prior to abandoning it.
Comment 1 Mark Hahnenberg 2012-04-23 20:19:29 PDT
Created attachment 138492 [details]
Patch
Comment 2 Geoffrey Garen 2012-04-23 21:16:34 PDT
Comment on attachment 138492 [details]
Patch

(1) Regression test, please.

(2) A better fix is to allocate the backing store first. That way, no special branching, and no zombie JSArray.

(3) Please re-verify that this inlining is still a performance win. It's a bit odd to have an optimization only in the slow JIT.
Comment 3 Geoffrey Garen 2012-04-24 09:25:27 PDT
<rdar://problem/11309000>
Comment 4 Mark Hahnenberg 2012-04-24 09:52:49 PDT
Created attachment 138583 [details]
Bencher results

These are the benchmark results for ToT without the optimization (just a stub call like we used to do) compared to the optimization along with this particular fix. Looks like a small win. I think when we finish bug 79198 arrays will be in a much better state in general.
Comment 5 Mark Hahnenberg 2012-04-24 11:18:53 PDT
Created attachment 138605 [details]
Patch
Comment 6 Geoffrey Garen 2012-04-24 12:32:50 PDT
Comment on attachment 138605 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=138605&action=review

Boy, those perf numbers are whisper-thin. Still, the fix is good, so let's take it.

> Source/JavaScriptCore/jit/JITInlineMethods.h:490
> +    // Allocate the backing store for the array. We allocate the storage first
> +    // because it could fail and we have to take the slow path, which would leave 
> +    // behind a zombie JSArray with inconsistent state, potentially causing a GC crash.

Hard to understand a comment about a potentially bad alternate version of the code.

I would just say, "We allocate the backing store first to ensure that garbage collection doesn't happen during JSArray initialization".
Comment 7 Mark Hahnenberg 2012-04-24 12:44:42 PDT
Fixed in http://trac.webkit.org/changeset/115096.
Comment 8 Rafael Weinstein 2012-05-10 10:04:31 PDT
Reopening to attach new patch.
Comment 9 Rafael Weinstein 2012-05-10 10:04:33 PDT
Created attachment 141188 [details]
Patch
Comment 10 Mark Hahnenberg 2012-05-10 10:08:56 PDT
(In reply to comment #8)
> Reopening to attach new patch.

I don't think this is the bug you meant to reopen.
Comment 11 Rafael Weinstein 2012-05-10 10:20:23 PDT
Sorry. No, it wasn't