427396 - Full woot.com blog archive makes Firefox use GBs of memory

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Zach]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.2)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

Whenever I goto that site in Firefox 3 the firefox memory resources go through the roof until i can barely access my computer and must kill the firefox.exe process.  I've experienced this in both Vista and XP with firefox 3, a buddy tested in Mac and had the same issue

Reproducible: Always

Steps to Reproduce:
1. Goto: http://www.woot.com/Blog/Archive.aspx?StartDate=3/2/2008
2. Watch memory resources go through the roof and computer begin to die.
3.
Actual Results:  
Memory resources shot through the roof and the computer began to die.

Comment 1

[Radek 'sysKin' Czyz]

Whoa, I can confirm.

Memory usage was kept in check (reached ~700 MB, after which was flushed back to 23 MB a couple of times) but VM size grew until it reached 2 GB and Minefiend died.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040606 Minefield/3.0pre

Comment 2

[Jesse Ruderman]

It's a 2.2MB page with 266 DiggThis iframes, so it's not entirely surprising that a web browser might have trouble displaying it.  Safari can handle it, fwiw.

Comment 3

[Dave Garrett]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Mandriva Linux 2008; KDE 3.5.9

Can confirm on Linux, too.  I had to kill it after a gig or two as it was stalling pretty much everything.

For this sort of thing, I think what we desperately need is a periodic prompt asking something to the effect of "This page is extremely large and is taking a long time to load.  Wait or stop?" like we have for slow scripts.  Though, I thought there was already something like this in place?

Comment 4

[Rafael Rivera]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

Confirmed in both Internet Explorer and Firefox.

Comment 5

[timeless]

people w/ enough swap are free to try following the steps in http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg to report a stack trace.

there are basically two possible paths:
1. we hit a malloc() failure and dereference null
2. we hit a new() failure and don't catch it

2 is more likely and won't be fixed until we redo our allocators. 1 is less likely and much easier to fix. just attach your stacks here and we'll see which it is.

Comment 6

[timeless]

jesse complained that my feedback wasn't helpful.
i tried loading this page in safari1 and the activity monitor sample said it got very very busy in js.
i loaded this page in ff2.0.0.13 which has noscript active, and the page loaded fine. enabling woot's domain alone doesn't kill my browser, although it isn't cheap.
 # full-url	file-name	function-name	start-line 	end-line	call-count	recurse-depth	total-time	min-time	max-time	avg-time	own-total-time	own-min-time, 	own-max-time	own-avg-time
http://www.woot.com/Scripts/DiggThis.js	DiggThis.js	DiggThis	2	14	265	0	4095.29	7.33	138.65	15.45	4095.29	7.33	138.65	15.45

Command: firefox-bin
Path:    /Volumes/New/Applications/Firefox 2.0.0.13.app/Contents/MacOS/firefox-bin
Version: 2.0.0.13 (2.0.0.13)
PID:     8961
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   <<00000000>> 	0x00000000 0 + 0
1   org.mozilla.firefox            	0x005c09ac nsJSContext::FireGCTimer() + 0xfc
2   libmozjs.dylib                 	0x2302f758 js_GC + 0x9f4
3   libmozjs.dylib                 	0x23003c74 JS_GC + 0x4c
4   org.mozilla.firefox            	0x005c0868 nsJSContext::Notify(nsITimer*) + 0x20
5   libxpcom_core.dylib            	0x2c04bb10 nsTimerImpl::Fire() + 0xc4

after a bit of tracing, i'm fairly certain the stacks i saw from my safari hangs are jQuery (i'm not blaming jQuery, merely noting it's an involved party, probably not entirely innocent but not necessarily the responsible party [which is probably woot])

#0: function anonymous(index=integer:0, type=string:"load") in <http://digg.com/js/101/jquery.js> line 25
call
#2: function anonymous(object=Array:{2}, callback=function:anonymous, args=void:void) in <http://digg.com/js/101/jquery.js> line 21
#3: function anonymous(elem=Window:{19}, types=string:"load", handler=function:anonymous, data=void:void) in <http://digg.com/js/101/jquery.js> line 25
#4: function bindReady() in <http://digg.com/js/101/jquery.js> line 27
#5: function anonymous(fn=function:anonymous) in <http://digg.com/js/101/jquery.js> line 26
#6: function (null)() in <http://digg.com/js/101/digg.js> line 123

is a startup stack to jQuery, not necessarily the right stack for what i saw, but it's the first that kinda matches.

Sadly, my attempt at using venkman profiler kinda failed.

if people want to try themselves, here's a general outline:
1. install venkman
2. open a browser window
3. open venkman
4. /fbreak woot 1
5. start profiling
6. load the page
7. you will hit breakpoints in venkman, you can execute this next line at any time, i did it when i was in DiggThis.js:
(function(x) {var w=x.write; var z=0; x.write = function document_write(s){ if (++z > 10) return; w.call(this, s) }})(document)

8. delete the breakpoints
9. continue
10. when the cpu comes back, stop profiling
11. profile>save as
use csv, name the file woot.csv.
12. open it in excel (google docs doesn't like the first line, you'd need to fix it to make it happy. I was using google docs and the experience was terribly frustrating - not google's fault, i'm fairly certain i filed a bug about the csv generator years ago).

what you should find is that jQuery is listed as most of the culprit. whether or not you do, attach the csv here :).

feel free to remove the lines that are from chrome/resources/extensions, if it doesn't say http/https, we don't need to see it.

please indicate if you're using ff2 or ff3, not that it should matter much.

people running on solaris or osx10.5 could instead use dtrace if they can get dtrace enabled builds.

if you happen to get this error:
Internal error dispatching command “save-profile”.
TypeError: scriptInstance has no properties @ <chrome://venkman/content/venkman-profiler.js> 332

I'm sorry, I don't know what it means (try a smaller cutoff, i think 10's too high)

Comment 7

[timeless]

Attachment: profile (limited to 10)

mostly functions from lines 33 - 34 of http://digg.com/js/101/omnidiggthis.js
also s_dr

i have a patch floating around that would have let me chase down object productions (it'd be very helpful here). But I'm using an official ff2.0.0.13 release and i'd need to pull sources for that and build (i can't use or build trunk on my mac)

Comment 8

[Rafael Rivera]

Attachment: stack trace, 01

Stack trace while the page was eating memories.

Comment 9

[Rafael Rivera]

Attachment: Firebug profile results, sorted by own func. time (tab delim.)

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

Attached a profile but I can't seem to reproduce the crashing now. After approx. 32 seconds, the page is fully loaded. Memory usage stops around 484mb.

Comment 10

[Wayne Mery (:wsmwk)]

still see this in V3?

Comment 11

[Tyler Downer [He/Him]]

No reply, INCO. Please reopen if you still see this bug in Firefox 3.5 or later in Firefox safe mode (http://support.mozilla.com/en-US/kb/Safe+Mode) or a new Firefox profile (http://support.mozilla.com/en-US/kb/Profiles) with updated plugins.