x = newGlobal() Int32Array = x.Int32Array x.p = ArrayBuffer() schedulegc(29); (function(stdlib, n, heap) { "use asm" var Int32ArrayView = new stdlib.Int32Array(heap) function f() { Int32ArrayView[1] } return f })(this, { f: new Function }, ArrayBuffer()) asserts js debug shell on m-c changeset d87b950c7a6f without any CLI arguments at Assertion failure: isObject(), at dist/include/js/Value.h This does not reproduce with --no-ion --no-baseline --no-asmjs, so filing as a separate bug from bug 889290. autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: http://hg.mozilla.org/mozilla-central/rev/866dbb8830d1 user: Terrence Cole date: Mon Jun 24 17:33:27 2013 -0700 summary: Bug 886575 - Update TypedArray's data slot when doing fallback marking for minor GC; r=sfink

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

This test caught two issues for me locally. The first is that the RelocatablePtr<PropertyName> that AsmJS::Global stores was getting inserted into the store buffer. Whoops. Surprised, once again, that this didn't bite earlier.

We're calling toObject() on the view's buffer heap slot and it is JSVAL_VOID. I did not know that a view could be created without an owning buffer, but the test is clearly doing exactly that. At least the fix is simple.

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/f95705c78b58 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/9a908856c46c

I didn't think about this enough. I was thinking that you were probably getting a NULL due to neutering, but I didn't really read the test case. So not only should it be impossible to create a view without a buffer, but neutering doesn't null out the buffer either. In other words: (In reply to Terrence Cole [:terrence] from comment #3) > Created attachment 773699 [details] [diff] [review] > Part 2 of 2 - the view's buffer slot can get nulled, apparently > > We're calling toObject() on the view's buffer heap slot and it is > JSVAL_VOID. I did not know that a view could be created without an owning > buffer, but the test is clearly doing exactly that. this shouldn't be possible. How can I reproduce this? I checked out d87b950c7a6f and built it on linux64, and could not reproduce.

oops, last comment should have been the needinfo?.

(In reply to Steve Fink [:sfink] from comment #6) > oops, last comment should have been the needinfo?. Try changeset 04d8c309fe72, I definitely reproduced this on a Mac 64-bit debug deterministic threadsafe js shell.

https://hg.mozilla.org/mozilla-central/rev/f95705c78b58 https://hg.mozilla.org/mozilla-central/rev/9a908856c46c

And I was able to reproduce on linux64: CC="gcc -m64" CXX="g++ -m64" ./configure --disable-optimize --enable-debug --enable-gcgenerational --enable-exact-rooting --with-system-nspr --enable-threadsafe --enable-more-deterministic --enable-gczeal --disable-intl-api --enable-profiling --enable-debug-symbols --enable-methodjit --enable-type-inference --disable-tests gcc (Gentoo 4.6.3 p1.13, pie-0.5.2) 4.6.3

On IRC, Steve was able to repro and found that the new code is correct.