STR: Load http://dl.dropbox.com/u/80664946/main.html?medium,medium The game gets stuck during the Preparing stage. I see this on the error console: [14:51:10.372] dc[y[(Gc >> 2)]] is not a function @ http://dl.dropbox.com/u/80664946/crunch-worker.js:110 Followed by a whole lot of errors such as: [14:51:10.372] uncaught exception: Unsupported image format undefined for packages/gk/fantasy/stone_ground_gk_v01/stone_ground_gk_v01_cc.dds

Note that this regression doesn't exist on my 8/20 nightly.

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=360ab7771e27&tochange=abc17059522b

Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/e33c175f6807 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120821162246 Bad: http://hg.mozilla.org/mozilla-central/rev/abc17059522b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120822030558 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e33c175f6807&tochange=abc17059522b Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/0fa2e09c092e Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120821080500 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/57c1c330e85f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120821090701 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0fa2e09c092e&tochange=57c1c330e85f

This is looking like a dup, I'll verify shortly.

Ok, the error during "Preparing" looks like it is fixed by the patch in bug 784639 which isn't yet on nightlies.

(which was indeed caused by the bug fingered in comment 3)

Coincidentally, a trunk (opt and debug) build produces a new error (very early, before downloading is finished) about a switch statement being too big. Seems unrelated, but I'll look into it.

So the "switch too large" bug is from the just-landed bug 568142. To be clear, the bug currently on nightly is fixed by bug 784639 and the current problem I'm seeing on trunk is not yet on nightly. Alex: we seem to have a file with a very very long column (colspan = 4492669 at the point of the error); can we have a better fallback than reporting an error? (This seems like a general problem for large minified JS programs.)

Just wanted to say thanks to everyone here for the quick and effective responses. We are about to launch BananaBread in a few days and two breakages on Nightly today was very worrying! I hope we can get the patch in comment 9 landed ASAP.

Hmm, can we back out bug 568142 and reland it with this fix? I've been meaning to do a blog post about profiling JS heavy applications and I have been meaning to use the experimental bananabread builds as an example, but this is blocking me, and my goal was to have that posted this week... :/

+1 to comment 11, if we can't land that fix immediately I support backing the breaking bug 568142 out. We are about to launch BananaBread in a few days and this can block us if it isn't fixed.

Comment on attachment 654811 [details] [diff] [review] Discard column information if the script is too large instead of aborting Review of attachment 654811 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/jit-test/tests/basic/bug785175.js @@ +5,5 @@ > +} > +str += 'var a = 1 + 1;'; > + > +// don't throw an exception even though the column numbers cannot be maintained > +eval(str); Could also test that the line number is correct even though the column info is discarded. r=me with or without that test.

I landed this on central directly so that I can trigger a nightly on it. Thanks for your patch, Alex! http://hg.mozilla.org/mozilla-central/rev/f2146a6c104e

Stuff like this is what makes this job exciting. "A source file with a four million column line?" Ran into one of those within a week!"

Thanks Alex, Jason and Ehsan for the quick work here! Very happy the next Nightly will be ok on this issue.