g = __defineGetter__("x", Iterator.prototype.iterator); c = x; delete x; Object.defineProperty(c, "x", ({ set: undefined })); ((function() { x = ""; (arguments.callee)() }))() crashes js opt and debug shells on m-c changeset df8f342e9a6b without any CLI arguments at js::EncapsulatedPtr My opt configure flags are: CC="clang -Qunused-arguments" AR=ar CXX="clang++ -Qunused-arguments" sh /Users/mozillaadmin/Desktop/js-opt-64-dm-ts-darwin-mozilla-central-145747-df8f342e9a6b-PHKxZv/compilePath/js/src/configure --target=x86_64-apple-darwin11.4.0 --enable-optimize --disable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --enable-methodjit --enable-type-inference --disable-tests --enable-more-deterministic --with-ccache --enable-threadsafe <other NSPR options> My debug configure flags are: CC="clang -Qunused-arguments" AR=ar CXX="clang++ -Qunused-arguments" sh /Users/mozillaadmin/Desktop/js-dbg-64-dm-ts-darwin-mozilla-central-145747-df8f342e9a6b-mhDfBN/compilePath/js/src/configure --target=x86_64-apple-darwin11.4.0 --enable-optimize --enable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --enable-methodjit --enable-type-inference --disable-tests --enable-more-deterministic --with-ccache --enable-threadsafe autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: http://hg.mozilla.org/mozilla-central/rev/c1ccfd8f31bf user: Eric Faust date: Fri Aug 30 18:50:36 2013 -0700 summary: Bug 824393 - Part 0: Open SetPropertyIC to cases with uncertain TI. (r=bhackett) This looks like a recursive buffer overflow but I'm setting s-s to be safe. Eric, is bug 824393 a likely regressor?

y = this; Object.defineProperty(__proto__, "set", ({})); valueOf = (function(j) { x = String; }); Object.defineProperty(this, "x", {}); y + this also crashes [@ js::EncapsulatedPtr]

Sometimes js::jit::SetPropertyIC::update appears at the top of the stack instead.

shape->setterObject() is NULL if |set| was defined as |undefined|. Add a check for this case. This shouldn't be an exploitable crash, just a NULL deref.

Amazingly, I found the stack for the situation that I was referring to in comment 2.

Also, efaust says this should be safe to open up, as it's "just a null-deref, even in optimized builds."