493625 - The same regexp matching code gives different results depending on whether a line "window;" is commented out or not.

Status: RESOLVED DUPLICATE of bug 493466

(Core :: JavaScript Engine, defect)

Description

[Michaeljohn Clement]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090517 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090517 Minefield/3.6a1pre

There are two files, pass.html and fail.html

Both of these files should show a textarea with "true" or "false".

The right answer is "true".

The only difference between the two files is that the "window;" line is 
commented out in fail.html.  I assume this reference to window prevents some 
kind of optimization from happening, causing pass.html to work where fail.html 
doesn't.

Reproducible: Always

Steps to Reproduce:
Load http://inimino.org/~inimino/tests/js/firefox/re/001/pass.html and http://inimino.org/~inimino/tests/js/firefox/re/001/fail.html
Actual Results:  
pass.html says "true" and fail.html says "false"

Expected Results:  
Both should say "true".

Comment 1

[Kevin Brosnan]

Attachment: Testcase from website

Comment 2

[Kevin Brosnan]

I see this on the trunk, not a problem on 1.9.1 using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090518 Shiretoko/3.5b5pre

Comment 3

[Robert Sayre]

a regression range would be great

Comment 4

[David Mandelin [:dmandelin]]

The 'window;' line might stop a trace from being recorded. I noticed there is a lot of upvar action in that code; I changed that recently and there is a known flaw in the design (see bug 493512). I will look into this.

Comment 5

[David Mandelin [:dmandelin]]

This was introduced by:

changeset:   28181:010768e6119c
user:        Brendan Eich <[e-mail]>
date:        Wed May 13 23:01:08 2009 -0700
summary:     Bug 492914 - TM: trace aborts due to flat closure analysis bug (r=mrbkap).

which is a 1-line patch to jsparse.cpp:2297:

-  outer_dn->pn_dflags |= (dn->pn_dflags & ~PND_PLACEHOLDER);
+  outer_dn->pn_dflags |= dn->pn_dflags & ~(PND_FORWARD | PND_PLACEHOLDER);

Comment 6

[David Mandelin [:dmandelin]]

This bug has the same cause as bug 493466.