function spaces(n) { if (n == 0) return ""; if (n == 1) return " "; var w = spaces(Math.floor(n/2)); return w + w + spaces(n%2); } var s = "<a b={\n1} />;/**/(((function c() {c}) for(d in [])))"; s = s.replace("/**/", "/*" + spaces(228) + "*/"); eval(s); asserts js debug shell at Assertion failure: cg->lexdeps.lookup(atom), at ../jsemit.cpp:2195 without -j on TM tip. It used to assert at Assertion failure: cg->upvars.lookup(atom), at ../jsemit.cpp:2033 as one bisects back in time. Many thanks to Jesse for helping to reduce this testcase. autoBisect shows this is probably related to bug 452498: The first bad revision is: changeset: 26784:2cf0bbe3772a user: Brendan Eich date: Sun Apr 05 21:17:22 2009 -0700 summary: upvar2, aka the big one take 2 (452498, r=mrbkap).

Added bug 527032 to the see also list, as it's also implicated as an upvar2 regression.

New js/src/tests/ecma_3/FunExpr/regress-528082.js addition to cover the bug underlying the botched assertion. /be

This bug could already be causing some woes in a release build, as the reference to the enclosing named lambda could get undefined or some random upvar (arg or stack local) slot instead of the denoted function object. Strongly suggest we take for 1.9.2. QA folks if you have any mystery bugs (I have seen a few lately), esp. ones pinned on upvar, please try this patch. /be

http://hg.mozilla.org/tracemonkey/rev/8808e68c71df Comment 3 missed beltzner's fine comment 1, which cites bug 527032 as another upvar2 regression. Does the patch I just landed on tm fix 527032? /be

A testcase for this bug was automatically identified at js/src/tests/ecma_3/FunExpr/regress-528082.js.

Testcases have been landed by virtue of being marked in-testsuite+ -> VERIFIED as well.