Closed Bug 490818 Opened 11 years ago Closed 11 years ago

Packed JS that works in Firefox 3.0 and all other browsers fails in Firefox 3.5

Categories

(Core :: JavaScript Engine, defect, P1)

1.9.1 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1

People

(Reporter: matthew.bugzilla, Assigned: brendan)

References

Details

(Keywords: verified1.9.1, Whiteboard: fixed-in-tracemonkey)

Attachments

(3 files)

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.
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Flags: blocking1.9.1?
Version: unspecified → 1.9.1 Branch
Assignee: general → brendan
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows XP → All
Priority: -- → P1
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.1
Flags: blocking1.9.1? → blocking1.9.1+
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
Blocks: upvar2
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
Attached patch fixSplinter Review
Attachment #376484 - Flags: review?(mrbkap)
Attachment #376484 - Flags: review?(mrbkap) → review+
Fixed in tm:

http://hg.mozilla.org/tracemonkey/rev/06ee37cea6af

/be
Whiteboard: fixed-in-tracemonkey
Severity: major → critical
Fixed in m-c:

http://hg.mozilla.org/mozilla-central/rev/a6068cf686fe

/be
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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
Depends on: 492355
Filed bug 492355 to track that regression.
No longer depends on: 492355
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
Status: RESOLVED → VERIFIED
Blocks: 500128
You need to log in before you can comment on or make changes to this bug.