686472 - Javascript executes complex callback code incorrectly

Status: RESOLVED DUPLICATE of bug 676343

(Core :: JavaScript Engine, defect)

Description

[Bruno Jouhier]

Attachment: ffbug.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 20110824172139

Steps to reproduce:

I executed one of my Javascript unit tests.

This unit test executes correctly on Chrome, Safari and node.js.
The test source is in the attached zip. Unzip them on a web server and load bug.html in FF.

The code is somewhat complex and implements an asynchronous quicksort function. It was auto-generated by streamline.js precompiler and I cleaned it up manually to narrow down the bug.

I could reproduce the bug with 32 and 64 bit versions of FF, both on Mac (FF 7.0) and Windows (6.0.2).



Actual results:

2 of the 3 tests failed.

If I put a breakpoint with Firebug on line 100, the test runs ok. If I do not put any breakpoint or the breakpoint on line 101 instead, the test fails!

Problem occurs around line 100 of file flows.js. The '_' closure contains the wrong 'fn' function when line 103 is executed (this is what I see with firebug when I set the breakpoint on 101 and step into the call on line 103).

I introduced a dummy 'foo' variable at top level in flows.js. If I uncomment the assignment to 'foo' at line 102, then the test runs ok. If I move the declaration of 'foo' just before line 102, then the test fails! (note that 'foo' has no relation whatsoever with the rest of the code)

The problem also goes away if I try to simplify the code further (eliminate the loading through require, eliminate indirection through __func, etc.), which is why my repro case is a bit hairy (but I did a lot of cleanup to reach this state). So this looks like a really nasty code generation bug (optimizer?) which only happens in a very peculiar code pattern (complex callback/closure scenario).


Expected results:

3 tests should have succeeded (as they do in other JS engines, and as they do in FF with small variations around this code).

Comment 1

[Matthias Versen [:Matti]]

The html contains absolute paths like ../node_modules/streamline/test/qunit/qunit.js , jquery and streamline/lib/compiler/transform

Comment 2

[Bruno Jouhier]

Ooops. I zipped from the wrong directory. I'm going to upload the right version.

Comment 3

[Bruno Jouhier]

Attachment: Source code for the repro

Disregard previous attachment. This is the right one.

Comment 4

[Matthias Versen [:Matti]]

I can confirm this with  Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110912 Firefox/9.0a1 SeaMonkey/2.6a1

Comment 5

[David Mandelin [:dmandelin]]

Is this a regression? When did it start failing?

Comment 6

[Matthias Versen [:Matti]]

I don't think it ever worked.
A nightly from 2007-06-05 shows this :
Error: [Exception... "'Error: module initialization failed: ./bug: TypeError: Object.keys is not a function' when calling method: [nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "<unknown>"  data: no]

The FF6.02 error message is simular:
Error: module initialization failed: ./bug: Error: source missing: ./bug keys=
Source File: http://mversen.de/mozilla/686472/require.js
Line: 128

the same test works in Opera11.5

Comment 7

[Jan de Mooij [:jandem]]

There's a problem with the testcase. path is "./bug" and then require.js does encodeURIComponent(path) + ".js". This causes us to request .%2Fbug.js and we get a 404. The same happens in Chrome.

After removing the encodeURIComponent I can reproduce the 2 test failures in Firefox 7 but not in the latest nightly. The deep nesting reminded me of bug 676343, and some further testing confirmed that it fails with a 09/01 nightly and works with a 09/04 nightly.

Bruno Jouhier, this issue has already been fixed for Firefox 9. See bug 676343 for more information and some workarounds you can use in the meantime.

Comment 8

[Bruno Jouhier]

Sorry for the glitches on the test case. I had to prune the code quite a bit to produce the repro and I only tested the final version on my machine (mac, FF 7)

Also, I did not hit the .%2Fbug.js problem because my node.js server does not bark on it (looks like it is decoding before parsing the slashes, which seems wrong).

Looks really similar to 676343 and I'm glad to hear that it has already been fixed.

I can live with it until FF 9 is released. We only run this sort function server side for now but our unit tests are designed to run both server side and browser side, which is why I ran into it.

Bruno