User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 I've been using http://smallsharptools.com/Downloads/SmallSharpTools.Packer/SmallSharpTools.Packer-4.0.3-Setup.msi to pack my JavaScript file for a few months (it's an offline variation of http://dean.edwards.name/packer/) and it works fine in all recent browsers, but it fails in Firefox 3.5 beta 4. I've tried to remove as much of the code as possible before submitting it, to make it easier to debug. The empty functions I've put in are necessary to make it fail. Reproducible: Always Steps to Reproduce: 1. Open the attached HTML file. Actual Results: Error: theMatrix is not a constructor Source File: FF35TestCase.html Line: 8 Expected Results: No error.

A regression range would help a ton here -- did it work in b3?

Yes, it worked in b3.

I bet its upvar. We should confirm and try to reduce.

I looked at this already, it's upvar2 all right -- somehow panAssembly when packed is a flat closure capturing undefined as the value of theMatrix. I'm off today but this should be easy enough to debug and fix tomorrow. /be

I should have dealt with this earlier, it's easy: JSTokenPtr uses uint16 for line and index in line numbering. The generated source here overflows, which utterly breaks the source-coordinate-based hoisting-vs-dominance judgments made by the upvar analysis. Easy fix, although it inflates the AST node by two words. /be

Fixed in tm: http://hg.mozilla.org/tracemonkey/rev/06ee37cea6af /be

Fixed in m-c: http://hg.mozilla.org/mozilla-central/rev/a6068cf686fe /be

This checkin is in a range suspected to have caused a TXul regression on OSX: Regression: Txul increase from 312.789 to 326.947 (4.53%) on Sun May 10 16:20:00 2009. Mac105 1.9.2 build 20090510132032 http://graphs.mozilla.org/#show=794371,794398,794384&sel=1241813896,1242159496 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6ea54bfd7c28&tochange=a6068cf686fe

Filed bug 492355 to track that regression.

When will this fix be available to test in a nightly build of Firefox?

Sorry, I see, it's only in 3.6a1pre at the moment.

Verified fixed on trunk and 1.9.1 with builds on OS X: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090522 Minefield/3.6a1pre ID:20090522032716 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090521 Shiretoko/3.5pre ID:20090521135222