643234 - JM: Crash [@ JSString::isAtomized]

Status: RESOLVED DUPLICATE of bug 639343

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: stack

for (i = 0; i < 10; i++) {
    Uint32Array().__proto__.__proto__ = new String("n")
    arguments.__proto__[
      Object.getOwnPropertyNames(arguments.__proto__)[
        Object.getOwnPropertyNames(arguments.__proto__).length - 1
      ] + "p"
    ] = 1
}
for (w in []) {
    print(Uint32Array()[0])
}

crashes js debug shell on TM changeset c811be25eaad with -m, -j and -a at JSString::isAtomized but does not seem to have any effect in opt shells.

Locking s-s just-in-case. May be related to bug 639343 ?

This was found using a combination of jsfunfuzz and jandem's method fuzzer.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   62389:1e38ca07f02f
user:        Bill McCloskey
date:        Tue Feb 15 08:40:21 2011 -0800
summary:     Bug 633929 - Fix methodjit-only and tracejit-only modes (r=dvander)

but this might be inaccurate..

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I don't think it's related to bug 633929. When I run a 64-bit build, I get the following failure:

Assertion failure: LIR type error (start of writer pipeline): arg 1 of 'orq' is 'immi' which has type int (expected quad): 0 (../nanojit/LIR.cpp:3238)

This happens with -j alone.

I don't understand this all that well, but here's what I think is happening. The first loop is somehow defining a property on Uint32Array's prototype. In the second loop, when we access Uint32Array()[0], we're pulling out this property, which is a string value. However, the tracer assumes that all GETELEM calls with an out-of-bounds indexes return undefined. So we have a case where the tracer thinks the value is statically undefined, and the interpreter thinks it's a string. This causes the assertion and, I think, the crash.

Jeff, could you take a look? I'm pretty sure that TraceRecorder::typedArrayElement needs some extra guards in the out-of-bounds case, but I don't understand the typed array stuff well enough to know what exactly is needed.