for (a in (eval("\ function() {\ return function() {\ yield ((function() {\ return d\ })())\ } ();\ var d = []\ }\ "))()); crashes js opt and debug shell on TM tip at js_GetUpvar near null. 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). Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000001c Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 js-opt-32-tm-darwin 0x0005cb1d js_GetUpvar + 29 1 js-opt-32-tm-darwin 0x0004f46d js_Interpret + 2765 2 js-opt-32-tm-darwin 0x00060b3f SendToGenerator(JSContext*, JSGeneratorOp, JSObject*, JSGenerator*, long) + 159 3 js-opt-32-tm-darwin 0x00060d7a generator_op(JSContext*, JSGeneratorOp, long*, unsigned int) + 218 4 js-opt-32-tm-darwin 0x0005efa0 js_Invoke + 1584 5 js-opt-32-tm-darwin 0x0005f7ac js_InternalInvoke + 140 6 js-opt-32-tm-darwin 0x00060617 js_CallIteratorNext + 151 7 js-opt-32-tm-darwin 0x00050dd8 js_Interpret + 9272 8 js-opt-32-tm-darwin 0x0005e65c js_Execute + 444 9 js-opt-32-tm-darwin 0x0000d91c JS_ExecuteScript + 60 10 js-opt-32-tm-darwin 0x000047c5 Process(JSContext*, JSObject*, char*, int) + 1621 11 js-opt-32-tm-darwin 0x00008726 main + 1734 12 js-opt-32-tm-darwin 0x0000264d _start + 208 13 js-opt-32-tm-darwin 0x0000257c start + 40

This issue occurs without -j.

I take it that you discovered this with a 1.9.2 RC2 build? Does it occur in RC1 and previous milestones?

(In reply to comment #2) > I take it that you discovered this with a 1.9.2 RC2 build? Does it occur in RC1 > and previous milestones? This occurs with 1.9.2 branch tip and 1.9.1 branch tip js shells. I'm not sure if the browser is as easily affected as well.

clearing nominations as it's unclear why we want to block on this - stability? security? do we know if it affects the browser? Renominate when you've got some deets for us! :)

This is similar to bug 528644, but in this case we have an upvar defined "above" (i.e., in an enclosing lexical scope) a generator function and used "below" the generator function. The above function has returned by the time we access the upvar. In general, it is possible that a generator function has "returned" by the time expressions inside it have been evaluated. (When the generator is called, it immediately returns, and then runs code inside it as yield is called.) Because the generator has returned, it is also possible that functions that enclose the generator have returned. So it is not valid to use the display optimization if the def-use chain crosses a generator function lexical scope. It seemed to me like it would be possible to trigger this kind of bug with MakeUpvarForEval as well, but I modified the test case so that the def-use chain also crosses the eval, and it didn't crash.

This is the dog that didn't bark in comment 5 para 2: function m() { var d = 73; for (a in (eval("\n\ function() {\n\ return function() {\n\ yield ((function() {\n\ print(d);\n\ return d\n\ })())\n\ } ();\n\ }\n\ "))()); } m();

function m() { var d = 73; return (eval("\n\ function() {\n\ return function() {\n\ yield ((function() {\n\ print(d);\n\ return d\n\ })())\n\ } ();\n\ }\n\ "))(); } m().next(); Is the dog that barks: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000018 0x00098b5e in js_GetUpvar (cx=0x309c00, level=1, cookie=262144) at jsinterp.cpp:2075 2075 JS_ASSERT(fp->script); Dave, can you add this to trace-test too? Thanks, /be

A testcase for this bug was automatically identified at js/src/jit-test/tests/closures/bug540243.js.