Wrong scoping for nested JavaScript closures

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
RESOLVED WORKSFORME
8 years ago
2 years ago

People

(Reporter: Adam Chlipala, Unassigned)

Tracking

1.9.1 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.19) 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:1.9.1.3) 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.

https://gist.github.com/1243491

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.
(Assignee)

Updated

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.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.