Wrong scoping for nested JavaScript closures




JavaScript Engine
8 years ago
2 years ago


(Reporter: Adam Chlipala, Unassigned)


1.9.1 Branch

Firefox Tracking Flags

(Not tracked)





8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20081204 Iceape/1.1.14 (Debian-1.1.14-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20090824 Firefox/3.5.3

The URL I included is from someone's blog post about a bug he thinks he found in SpiderMonkey.  I've encountered a similar problem for a different (ugly, auto-generated) script in Firefox but not in any other browser.

Reproducible: Always

Steps to Reproduce:
Run the code example from the URL I gave.
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.9.1 Branch

Comment 1

6 years ago
I just re-discovered this problem independently. The original link is broken, but here is the code that fails for me. `assert(test(1)==2)` claims that x16 is undefined.


The gist contains an F# script to generate the code for arbitrary nesting level.

Chrome succeeds at k=256.

Please consider treating this as high priority. This kind of basic correctness is essential for using JavaScript as a compiler backend (WebSharper, Ur).

Just in case, the generated code below:

/// generated JavaScript for k=16

function bind(x,f) {return f(x)}
function test(x0) {
var k0;
k0 = function (x1) {
var k1;
k1 = function (x2) {
var k2;
k2 = function (x3) {
var k3;
k3 = function (x4) {
var k4;
k4 = function (x5) {
var k5;
k5 = function (x6) {
var k6;
k6 = function (x7) {
var k7;
k7 = function (x8) {
var k8;
k8 = function (x9) {
var k9;
k9 = function (x10) {
var k10;
k10 = function (x11) {
var k11;
k11 = function (x12) {
var k12;
k12 = function (x13) {
var k13;
k13 = function (x14) {
var k14;
k14 = function (x15) {
var k15;
k15 = function (x16) {
var k16;
k16 = function (x17) {
return x16 + 1;
return bind(x16,k16)
return bind(x15,k15)
return bind(x14,k14)
return bind(x13,k13)
return bind(x12,k12)
return bind(x11,k11)
return bind(x10,k10)
return bind(x9,k9)
return bind(x8,k8)
return bind(x7,k7)
return bind(x6,k6)
return bind(x5,k5)
return bind(x4,k4)
return bind(x3,k3)
return bind(x2,k2)
return bind(x1,k1)
return bind(x0,k0)
Anton, can you reproduce the problem in comment 2 in a nightly build?  I'm trying to understand some of the relevant code for an unrelated matter, and this report happened to come to mind.


3 years ago
Assignee: general → nobody

Comment 3

2 years ago
No longer reproducible - Resolving as WFM.

Tested with k=16 and k=256. (k=256 does not work in the interpreter due to overrecursion, but works in baseline and ion.)
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.