Closed Bug 707950 Opened 8 years ago Closed 8 years ago

Site causes FF to freeze - Chrome & Safari work

Categories

(Core :: JavaScript Engine, defect)

9 Branch
x86
All
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 697861
Tracking Status
firefox9 + affected
firefox10 --- unaffected

People

(Reporter: rvjanc, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [qa+])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20100101 Firefox/9.0
Build ID: 20111130065942

Steps to reproduce:

Went to this site http://redditgifts.com/statistics/secret-santa-2011/map/


Actual results:

Firefox freezes. Chrome and Safari work fine.


Expected results:

A map should load. FF froze before the map loaded.
OS: Mac OS X → All
works for me with Firefox 8.0 and Seamonkey trunk on win32.
Can you please try it again in the Firefox safemode: http://support.mozilla.com/en-US/kb/Safe+Mode
Safe mode test still results in FF freeze. Here is additional info

http://forums.mozillazine.org/viewtopic.php?f=23&t=2382383

While I'm on a Mac the OP is using Win. NOTE: I also tried with a "blank" profile and it froze.
>Safe mode test still results in FF freeze
The safemode fixed the problem for the guy in the mozillazine thread....
He downgraded to FF8

FlyingPenguins posted - So it turns out that I actually didn't test this problem with Firefox 8, so I downgraded...
I tested it with both a blank profile and my preexisting one with all of my addons and custom preferences, and the problem no longer occurs in either. The browser is still very slow to load the page, and hangs for a few seconds, but at least it will finish loading the page and won't bring down my entire system

I will test in FF8 and let you know.
Just tried in FF8.0.1 with an empty profile and there is no problem. Seems to be a FF9 issue.
Yes, This problem happens only in Firefox9.0beta.
Regression window(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/85d9c87ef45a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110829 Firefox/9.0a1 ID:20110829154046
Freeze:
http://hg.mozilla.org/mozilla-central/rev/b61af4d7dc7c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110829 Firefox/9.0a1 ID:20110829214159
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=85d9c87ef45a&tochange=b61af4d7dc7c

Regression window(jm)
Works:
http://hg.mozilla.org/projects/jaegermonkey/rev/058032661e2f
Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110727 Firefox/8.0a1 ID:20110727040312
Freeze:
http://hg.mozilla.org/projects/jaegermonkey/rev/d43c6dddeb2b
Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110729 Firefox/8.0a1 ID:20110729040250
Pushlog:
http://hg.mozilla.org/projects/jaegermonkey/pushloghtml?fromchange=058032661e2f&tochange=d43c6dddeb2b

WORKAROUND:
javascript.options.methodjit.content to false



FYI,It works in Aurora10.0a2.
Works again(m-c);
Freeze:
http://hg.mozilla.org/mozilla-central/rev/df4b49fffc78
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111030 Firefox/10.0a1 ID:20111030010009
Works again:
http://hg.mozilla.org/mozilla-central/rev/945f64763a70
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111030 Firefox/10.0a1 ID:20111030093412
Works again pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=df4b49fffc78&tochange=945f64763a70

Works again(m-i);
Freeze:
http://hg.mozilla.org/integration/mozilla-inbound/rev/eaaab958a659
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111028 Firefox/10.0a1 ID:20111029161714
Works again:
http://hg.mozilla.org/integration/mozilla-inbound/rev/1b4d0987b18d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111029 Firefox/10.0a1 ID:20111029181715
Works again pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=eaaab958a659&tochange=1b4d0987b18d
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Brian, this looks like a TI regression that was fixed in one of the three checkins in <http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=eaaab958a659&tochange=1b4d0987b18d>.  Is it possible to backport the relevant checkin to Fx9?
(In reply to Boris Zbarsky (:bz) from comment #7)
> Brian, this looks like a TI regression that was fixed in one of the three
> checkins in
> <http://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=eaaab958a659&tochange=1b4d0987b18d>.  Is it possible
> to backport the relevant checkin to Fx9?

Do we know which cset in that range fixed things?  1b4d0987b18d seems the most likely, and it is a small patch which has not caused problems since landing.  It could also be aa953731b2c6, which is a bigger patch but is just deleting code.
FYI,
In local build(non PGO),
revert the source tree back to 1814bb5292a4 : works
revert the source tree back to aa953731b2c6 : works
revert the source tree back to eaaab958a659 : freezes
Status: UNCONFIRMED → NEW
Ever confirmed: true
In local build(non PGO),
revert the source tree back to d37f88fa3713 : freezes
revert the source tree back to 65c33bba9d01 : freezes
revert the source tree back to 235a8bfe2665 : works
revert the source tree back to c7a7d9ff99da : works

The problem is triggered by:
65c33bba9d01	Brian Hackett — [INFER] Reduce inference-related script overhead, bug 674609.
(In reply to Alice0775 White from comment #9)
> FYI,
> In local build(non PGO),
> revert the source tree back to 1814bb5292a4 : works
> revert the source tree back to aa953731b2c6 : works
> revert the source tree back to eaaab958a659 : freezes

Does this mean aa953731b2c6 fixed it?
(In reply to David Mandelin from comment #11)
> (In reply to Alice0775 White from comment #9)
> > FYI,
> > In local build(non PGO),
> > revert the source tree back to 1814bb5292a4 : works
> > revert the source tree back to aa953731b2c6 : works
> > revert the source tree back to eaaab958a659 : freezes
> 
> Does this mean aa953731b2c6 fixed it?
I mean
built from cset aa953731b2c6 works without freeze.
built from cset eaaab958a659 freezes.
> Does this mean aa953731b2c6 fixed it?

Sounds like it to me.
Will this make it into FF9 final or FF10?
It's already made it into Firefox 10.  See comment 6 and the status flags.

The discussion is all about what will happen with Firefox 9.
Depends on: 697861
I just added an approval request to bug 697861, the patch is not small but is pretty much just deleting code.
Whiteboard: [qa+]
This is actually a dup of 697861, right?
Seems like it, yes.
Then let's mark it as such, we can still reopen if we find out it's not.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 697861
You need to log in before you can comment on or make changes to this bug.