Closed Bug 479487 Opened 15 years ago Closed 15 years ago

TM: js_Array_dense_setelem can call arbitrary JS code

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: igor, Assigned: gal)

References

Details

(Keywords: testcase, verified1.9.1, Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

Currently js_Array_dense_setelem delegates to array_setProperty difficult cases of assigning array properties. But that function can turn the array into slow one and call arbitrary JS code through a setter on the prototype as the following example demonstrates:

@watson~/m/tm/js/src> cat ~/s/y.js
Array.prototype[1] = 2;

Array.prototype.__defineSetter__(32, function() { print("Hello from arbitrary JS");});
Array.prototype.__defineGetter__(32, function() { return 11; });

function f()
{
    var a = [];
    for (var i = 0; i != 10; ++i) {
        a[1 << i] = 9999;
    }
    return a;
}

f();
@watson~/m/tm/js/src> schroot -- ~/build/js32.tm.dbg/js -j ~/s/y.js
I: [i386 chroot] Running command: “/home/igor/build/js32.tm.dbg/js -j /home/igor/s/y.js”
Assertion failure: cx->bailExit, at /home/igor/m/tm/js/src/jstracer.cpp:4640
E: Child terminated by signal ‘Trace/breakpoint trap’
@

This is a regression introduced in the changeset 980c23ed651e, http://hg.mozilla.org/mozilla-central/rev/980c23ed651e/ (no bug number).
We should grow on-trace. Taking. Thanks for the testcase!
Assignee: general → gal
(I mean grow dense on trace, as long not OOM, but never go slow)
Attached patch patchSplinter Review
Attachment #363357 - Flags: review?(jorendorff)
Comment on attachment 363357 [details] [diff] [review]
patch

>diff --git a/js/src/jsarray.cpp b/js/src/jsarray.cpp
>--- a/js/src/jsarray.cpp
>+++ b/js/src/jsarray.cpp
>@@ -800,21 +800,31 @@
> {
>     JS_ASSERT(OBJ_IS_DENSE_ARRAY(cx, obj));
> 

Could the fast array guard can also be moved into js_Array_dense_setelem for smaller traced code?
The opposite. Shaver will try to pull the fast path out of the builtin and only call to realloc.
(In reply to comment #5)
> The opposite. 

Oh, a call is that expensive? I guess FASTCALL means SLIGHTLY_FASTER_THEN_YOUR_AVERAGE_SLOW_CALL ;)
The call's probably not too horrible, but its need to spill ecx and edx for the first two arguments is probably the killer, combined with likely-dumb codegen that starts with the usual function prologue.
Comment on attachment 363357 [details] [diff] [review]
patch

Very nice.
Attachment #363357 - Flags: review?(jorendorff) → review+
Comment on attachment 363357 [details] [diff] [review]
patch

>+    /*
>+     * Let the interpreter worry about negative array indexes.
>+     */
>+    if (i < 0)
>+        return JS_FALSE;
>+
>+    /*
>+     * If needed, grow the array as long it remains dense, otherwise fall off
>+     * trace.
>+     */
>+    jsuint u = i;
>+    jsuint length = ARRAY_DENSE_LENGTH(obj);
>+    if (((jsuint)u >= length) && (INDEX_TOO_SPARSE(obj, u) || !EnsureLength(cx, obj, u + 1)))

Drive-by nits (I didn't check for trailing whitespace :-P):

u is a jsuint, no need to cast.

Don't overparenthesize relationals and equality ops against &&.

>+        return JS_FALSE;
>+
>+    if (obj->dslots[u] == JSVAL_HOLE) {
>+        if (cx->runtime->anyArrayProtoHasElement)
>+            return JS_FALSE;
>+        if (u >= jsuint(obj->fslots[JSSLOT_ARRAY_LENGTH]))

C++-style constructor cast looks good here. Just noticing unnecessary (jsuint) cast earlier was C-style. Prefer C++-style now outside of jsapi.h and its includes.

/be
(In reply to comment #9)
> C++-style constructor cast looks good here. Just noticing unnecessary (jsuint)
> cast earlier was C-style. Prefer C++-style now outside of jsapi.h and its
> includes.

Do you mean here just the constructor calls and not (static|const|reinterpret>_cast operators?
(In reply to comment #10)
> (In reply to comment #9)
> > C++-style constructor cast looks good here. Just noticing unnecessary (jsuint)
> > cast earlier was C-style. Prefer C++-style now outside of jsapi.h and its
> > includes.
> 
> Do you mean here just the constructor calls and not
> (static|const|reinterpret>_cast operators?

We're still throwing C-style casts around instead of reinterpret_cast<T>(v) casts, I know. We should use the long_winded but type-safer variants, and Waldo at least has started. It'll be a while yet, or a post-3.1 flag day, before we get rid of all the legacy C-style pointer-type casts.

/be
http://hg.mozilla.org/tracemonkey/rev/2f7313f0696f
Flags: blocking1.9.1?
Priority: -- → P2
Whiteboard: fixed-in-tracemonkey
Flags: blocking1.9.1? → blocking1.9.1+
http://hg.mozilla.org/mozilla-central/rev/2f7313f0696f
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Keywords: testcase
http://hg.mozilla.org/tracemonkey/rev/2013ac7156d9

/cvsroot/mozilla/js/tests/js1_5/extensions/regress-479487.js,v  <--  regress-479487.js
initial revision: 1.1
Flags: in-testsuite+
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: