The following testcase asserts on mozilla-central built with --enable-exact-rooting --enable-gcgenerational, revision 9ca690835a5e (run with ): gczeal(11); var otherGlobal = newGlobal('new-compartment'); function test(str, arg, result) { var fun = new Function('x', str); var code = "(function (x) { " + str + " })"; var c = clone(otherGlobal.evaluate(code, {compileAndGo: false})); assertEq(c.toSource(), eval(code).toSource()); } test('return let (y) x;'); test('return let (x) "" + x;', 'unicorns', 'undefined'); test('return let (y = x) (y++, "" + y);', 'unicorns', 'NaN'); test('return let (y = 1) (y = x, y);'); test('return let ([] = x) x;'); test('return let ([, ] = x) x;'); test('return let ([, , , , ] = x) x;'); test('return let ([[]] = x) x;'); test('return let ([[[[[[[[[[[[[]]]]]]]]]]]]] = x) x;'); test('return let ([[], []] = x) x;'); test('return let ([[[[]]], [], , [], [[]]] = x) x;');

jsfunfuzz got this too.

The jitcode version of IsInsideNursery does not know about the post-barrier verifier, so we can end up calling the PostBarrier VMFunction on edges which are only virtually "in the nursery". We can simply filter these edges after the API call instead of before at the cost of a bit of performance when running the post-barrier verifier.

Comment on attachment 759934 [details] [diff] [review] v0 Review of attachment 759934 [details] [diff] [review]: ----------------------------------------------------------------- Sorry for the delay. ::: js/src/ion/VMFunctions.cpp @@ +573,5 @@ > +#ifdef JS_GC_ZEAL > + /* The jitcode version of IsInsideNursery does not know about the verifier. */ > + if (rt->gcVerifyPostData && rt->gcVerifierNursery.isInside(obj)) > + return; > +#endif What does having objects that are only "virtually" in the nursery allow, now that we have an actual nursery?

(In reply to Brian Hackett (:bhackett) from comment #4) > > What does having objects that are only "virtually" in the nursery allow, now > that we have an actual nursery? The only advantage of this is that we don't have to worry about objects dying because of missing barriers. My thinking was that for browser builds we would want to report errors rather than crashing so that we could fix more than one error between recompiles. Given how many random bugs this scheme has caused, not to mention extra complexity, I'm starting to think this feature is probably not worth the hassle. We need to revisit the verifier anyway to make it faster before it will be useful for analysing the browser: removing the set would be helpful there too. I think we should probably check this in as is for now and I will try to rewrite the verifier as soon as GGC is green on inbound.