1161346 - Crash [@ js::UnboxedArrayObject::create]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

function f() {
    x = [];
    x.push(false);
}
f();
f();

crashes js debug shell on m-c changeset 102d0e9aa9e1 with --fuzzing-safe --no-threads --ion-eager --unboxed-arrays at js::UnboxedArrayObject::create.

Configure options:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

python -u ~/fuzzing/js/compileShell.py -b "--enable-debug --enable-more-deterministic --enable-nspr-build" -r 102d0e9aa9e1

=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20150503013437" and the hash "599a8abf54a3".
The "bad" changeset has the timestamp "20150503081437" and the hash "020c6a559e3a".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=599a8abf54a3&tochange=020c6a559e3a

Brian, is bug 1146597 a likely regressor?

Comment 1

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

Attachment: stack

(lldb) bt 5
* thread #1: tid = 0x15e468, 0x000000010033f126 js-dbg-64-dm-nsprBuild-darwin-102d0e9aa9e1`js::UnboxedArrayObject::create(js::ExclusiveContext*, JS::Handle<js::ObjectGroup*>, unsigned int, js::NewObjectKind) + 85 at UnboxedObject.cpp:1247, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010033f126 js-dbg-64-dm-nsprBuild-darwin-102d0e9aa9e1`js::UnboxedArrayObject::create(js::ExclusiveContext*, JS::Handle<js::ObjectGroup*>, unsigned int, js::NewObjectKind) + 85 at UnboxedObject.cpp:1247
    frame #1: 0x000000010033f0d1 js-dbg-64-dm-nsprBuild-darwin-102d0e9aa9e1`js::UnboxedArrayObject::create(cx=<unavailable>, group=<unavailable>, length=<unavailable>, newKind=GenericObject) + 337 at UnboxedObject.cpp:1035
    frame #2: 0x000000010020954a js-dbg-64-dm-nsprBuild-darwin-102d0e9aa9e1`js::NewArrayOperation(cx=0x0000000101ea5180, script=<unavailable>, pc=<unavailable>, length=0, newKind=TenuredObject) + 362 at Interpreter.cpp:4718
    frame #3: 0x00000001004124f4 js-dbg-64-dm-nsprBuild-darwin-102d0e9aa9e1`js::jit::DoNewArray(cx=0x0000000101ea5180, frame=<unavailable>, stub=0x0000000101eb9988, length=0, res=<unavailable>) + 260 at BaselineIC.cpp:1681
    frame #4: 0x0000000101f8b187
(lldb)

Comment 2

[Brian Hackett [Laid off!]]

Attachment: patch

Hmm, I guess I missed a possible capacity we can have with the possible combinations of architecture, object size and unboxed type element size.  (If we hit this again I'll go and write a script to figure out the possible capacities programmatically.)

Comment 3

[Jan de Mooij [:jandem]]

Comment on attachment 8602279 [details] [diff] [review]
patch

Review of attachment 8602279 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/vm/UnboxedObject.cpp
@@ +1263,3 @@
>  };
>  
>  static const uint32_t MebiCapacityIndex = 39;

Should we update this constant? There is a MOZ_ASSERT(CapacityArray[MebiCapacityIndex] == Mebi) though, does it hit on jit-tests? Maybe it should be a static assert?

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5b68de5f1dc9

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5b68de5f1dc9