User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110902 Firefox/9.0a1 Build ID: 20110902030838 Steps to reproduce: Opening a user-generated map on Google Maps. For example, http://maps.google.fr/maps/ms?ie=UTF8&hl=fr&msa=0&msid=210131682796347244485.000472ea3aa4ad224cdfb&ll=48.872393,2.3909&spn=0.279109,0.700378&t=p&z=11&lci=transit_comp Actual results: Google Maps opens correctly, but : * Only one symbol is listed on the left menu * No symbol is shown on the user map Expected results: Google Maps should have been showing the full list on symbols, both on the left menu and on the map.

Bug appears on my 2 test configurations : * Firefox nightly, Ubuntu 11.04 64 bits * Firefox nightly, Windows XP 32 bits Both use French locale.

Confirmed And an an error in error console as follows: Error: YP is not defined Source file: http://maps.gstatic.com/cat_js/intl/fr_fr/mapfiles/363c/maps2/%7Bmain,mod_util,mod_actbr,mod_appiw,mod_info,mod_kml,mod_mp,mod_ms,mod_mssvt,mod_rst%7D.js Line: 803 Regression window(cached m-c hourly), Works: http://hg.mozilla.org/mozilla-central/rev/005bce677a00 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110831 Firefox/9.0a1 ID:20110831030834 Fails: http://hg.mozilla.org/mozilla-central/rev/c7e6f57e1732 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110831 Firefox/9.0a1 ID:20110831014759 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=005bce677a00&tochange=c7e6f57e1732 Regression window(cached m-i hourly), Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/f1dbc0a63703 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110830 Firefox/9.0a1 ID:20110830125405 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/9eaca4ef5880 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110830 Firefox/9.0a1 ID:20110830142636 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f1dbc0a63703&tochange=9eaca4ef5880

triggered by; 9eaca4ef5880 Jason Orendorff — Bug 561359 - Predication of method optimization is too dynamic, causing "Assertion failure: &shape.methodObject() == &prev.toObject()". r=dvander.

I actually noticed this bug in Nightly yesterday. Never dreamed it could actually be my fault! I'll look into it today. It might be a duplicate of bug 684178, in which case the fix is already in hand and awaiting review.

Taking. I suspect this is *not* a duplicate, but it's hard to tell.

Slightly reduced by 20% but still large. No longer seems to require one to be offline to reproduce. More reduction in progress but checkpointing is important.

Checkpoint: after a night of reduction, the main gmaps.html file is now reduced by >40% from jorendorff's testcase set.

< 30 lines total, including 8 crucial lines: try { t = function() { b = function() {} } } catch (e) {} setTimeout(function() { o(0, "").k() })

> Created attachment 560321 [details] > fully reduced testcase I'm not entirely sure if this testcase exhibits the bug yet, will confirm later.

No, this does not exhibit the bug. The same exception occurs both in buggy and non-buggy builds.

Comment on attachment 560321 [details] fully reduced testcase Starting all over again. :(

As someone following along at home, is the exception from the previous reduced testcase a legitimate problem separate from this bug, or is Firefox behaving correctly?

(In reply to Emanuel Hoogeveen from comment #13) > As someone following along at home, is the exception from the previous > reduced testcase a legitimate problem separate from this bug, or is Firefox > behaving correctly? Apparently I think it's Firefox behaving correctly. I've thrown that out and started from jorendorff's original testcase. Just to update, I have a testcase 20% smaller than the original that shows the error in Nightlies but not in Aurora. (according to the regression window in comment 2 or 3) This should be the symptom that I should have looked out for, which the original exhibits. Reducing this one is a pain due to its complexity. Beautified, the original one is about 27,000 lines. (Ouch!)

Here's a zipped testcase w/ 2 files, 20+% smaller than the original. Shows the reference error (IP is not defined) in Nightlies, but not in Aurora. (similar to the original testcase)

Here's another zipped testcase w/ 2 files, even smaller. Shows the reference error (IP is not defined) in Nightlies, but in Aurora, this shows a Reference error for $u being not defined (differing from the original testcase which does not pop up anything at all in Aurora) Jason, is this set of testcase on the right track, or is the previous one the only correct one?

Offline, Jason mentions that I should look out for the "IP is not defined" message. The attached zip file contains a testcase (not yet fully reduced) that gives the aforementioned ReferenceError on Nightly but not on Aurora. (down to ~10,000 lines) Thanks go out to Waldo, Jesse and decoder for their help on tips to speeding up the reduction process amongst other stuff.

Reduced over the weekend. Shows the "IP is not defined" error in Nightly 13092011 but not in Aurora 14092011.

Reduced again. Shows the "IP is not defined" error in Nightly 16092011 but not in Aurora 14092011. Handing off to decoder to see how he can further reduce.

Turns out that there were a couple lines which were hundreds of thousands of characters long, and when that was beautified, (self note: watch for escaped double quotes, back slashes, as well as Regular Expressions), the testcase blew up to 13,500 lines. Checkpointing. decoder and I also found out that this error may have different testcases on different platforms. The testcase that is attached here is tested to show up the "IP is not defined" error on Windows 20 Sep 2011 nightly rev 648d084ca28e but not on the Windows Aurora 14 Sep 2011 rev 63d1f8b24911.

< 1,000 line fully beautified checkpoint

Off to langDDMin for decoder, testcase tested on Win7 nightly vs aurora.

> Created attachment 562266 [details] > < 700 line testcase jorendorff, it's starting to get extremely tough for the reducers to further reduce this testcase. Does this testcase reproduce the "IP is not defined" error for you on Nightly but not on Release?

The HTML file for this is: <!DOCTYPE html> <html> <head> </head> <body> <script type="text/javascript" src="gmapsLong.js"></script> </body> </html>

Shell test case: "use strict"; eval("var x = {}; ({p: function() { x.m; }}).p();"); Expected: does nothing Observed: throws ReferenceError: x is not defined

The same bytecode is emitted before and after rev 9eaca4ef5880: ... 00024: newinit 1 00027: lambda (function () {"use strict";x.m;}) 00030: nullblockchain 00031: initmethod "p" 00034: endinit 00035: callprop "p" 00038: call 0 ... This lambda was never a candidate for the method optimization, though. Both before and after, that JSOP_NULLBLOCKCHAIN is incorrect. It must be that the old dynamic checks prevented the bug from biting, and the new static behavior doesn't.

I didn't mean to change tracking-firefox10 from + to ?. I don't know how that happened. I don't have privileges to set it back to +.

The "var x" is behaving correctly, I think, and creating a variable in the implicitly created strict direct eval scope (not the global object). I think the bug is that the lambda is compiled as a null closure, even though it references x. I see two possible fixes. 1. Treat strict direct eval scopes more like function scopes. On leaving one, do all the stuff we do in LeaveFunction to fix up yet-to-be-resolved lexdeps. 2. Treat strict direct eval scopes as dynamic for the purposes of the inAnyDynamicScope() call in Parser::setFunctionKinds. The latter is easier.

The status quo in BindTopLevelVar makes option 1 implausible. Here's option 2. I'm building a browser now to see if it fixes Google Maps.

Comment on attachment 569792 [details] [diff] [review] v1 Review of attachment 569792 [details] [diff] [review]: ----------------------------------------------------------------- Interesting to see that Maps is using strict mode... ::: js/src/jit-test/tests/closures/bug684489.js @@ +1,1 @@ > +"use strict"; This testcase doesn't look like the one pasted in the bug...

(In reply to comment #30) > I'm building a browser now to see if it fixes Google Maps. It does! (In reply to comment #31) > This testcase doesn't look like the one pasted in the bug... Splinter bug. The patch is correct. https://hg.mozilla.org/integration/mozilla-inbound/rev/f7a30d961569

How about Aurora? This bug affects Aurora9.0a2.

Comment on attachment 569792 [details] [diff] [review] v1 [Triage Comment] * Approved for Aurora since 690157 suggests that this is a regression in 9

Adding [qa+] to add visibility during bug verification. High impact, has a testcase, and it should be easy to verify.

Verified issue using the test case attached in comment 26 - the ReferenceError: "x is not defined" is not thrown. Verified on Windows XP, Windows 7, Ubuntu 11.10 and Mac OS X 10.6 with Firefox 9.0b2, the latest Nightly and Aurora. Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0 Mozilla/5.0 (Windows NT 5.1; rv:10.0a2) Gecko/20111121 Firefox/10.0a2 Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110902 Firefox/9.0a1 Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20100101 Firefox/9.0 Mozilla/5.0 (X11; Linux x86_64; rv:10.0a2) Gecko/20111121 Firefox/10.0a2 Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111121 Firefox/11.0a1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20100101 Firefox/9.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0a2) Gecko/20111121 Firefox/10.0a2 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0a1) Gecko/20111121 Firefox/11.0a1 Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0 Mozilla/5.0 (Windows NT 6.1; rv:10.0a2) Gecko/20111121 Firefox/10.0a2 Mozilla/5.0 (Windows NT 6.1; rv:11.0a1) Gecko/20111121 Firefox/11.0a1