239330 - vsz and rss memory bloat when accessing that page (page size == 1Mb

Status: RESOLVED DUPLICATE of bug 216418

(Core :: General, defect)

Description

[Richard Hubbe11]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

That page causes firefox to bloat and makes it unresponsive, might
be paging to disk as it bloats.

Reproducible: Always
Steps to Reproduce:
1.go to page
2.
3.

Actual Results:  
That page causes firefox to bloat and makes it unresponsive, might
be paging to disk as it bloats.

Expected Results:  
quickly loaded the page with ease

Comment 1

[Bruno 'Aqualon' Escherl]

Can confirm that bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040423.

The load time of the page was ~60s and the memory usage raised from 15MB to
180MB. For comparison, IE6 only needs ~15s and memory usage raises slightly from
10MB to 20 MB.

I see that behaviour with disk cache and without disk cache.

Bruno

Comment 2

[Thomas Harold]

(In reply to comment #1)

Windows XP SP 1 running the Win32 version of Firefox 0.8 (downloaded from the
mozilla.org website) on that page causes memory usage to go from 67MB to 217MB.
 Doing a "View Source" on the page and then scrolling down will sometimes cause
CPU to jump to 80-90% for a few seconds.  Other then that it doesn't seem to
affect browser responsiveness (this machine is a 2-year old laptop with 768MB
RAM, only 584MB in use).

Nothing complex in the HTML either, one thing that I did notice is that the
entire page is supposed to be enclosed in a < pre >< /pre > tag... but the page
is missing the closing < /pre > and the entire content occurs *after* the
closing of the body and html tags.

Fixing the improper tags (adding a closing PRE at the end, moving the closing
BODY/HTML tags also to the end of the document) and viewing the page again
*still* causes memory usage to jump from 200MB to 361MB.  That dropped to 234MB
after I viewed the source.  However, viewing page source and switching back and
forth between the source window and Firefox 0.8 window doesn't exhibit the high
CPU usage as the uncorrected page.

Switching to a Win2000 server (latest service packs), same version of Firefox
0.8 but with blank profile, no extensions.  Memory usage jumps from 16MB to
162MB with the *fixed* version of the page loaded from local disk.  (Fixed
meaning that the closing PRE was added, the BODY/HTML tags were moved to the
bottom of the page.)  Also tried removing the PRE tag entirely.  Removing the <
pre > tags from the document reduces memory usage to 73MB instead of 162MB.

Comment 3

[Nile]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040727 Firefox/0.9.1+

Confirming behavior. Firefox shoots from about 25mb usage to 177mb. I have 512mb
total. No hard disk swapping occurred. Not sure if this is a bug however..

Comment 4

[Richard Hubbe11]

Still occurs in 0.9.3.  Does firefox use sbrk, mmap, malloc or ??  Perhaps the
memory allocation/deallocation scheme needs to be scrutinized.  If I can I will
try to see if nay page faults are occurring.  This may provide further insight
into the problem.

Comment 5

[Bernard Alleysson]

probably a dupe of bug 112738

Comment 6

[Bernard Alleysson]

*** This bug has been marked as a duplicate of 112738 ***

Comment 7

[Boris Zbarsky [:bzbarsky]]

The allocators used in the source are C malloc() and C++ new().

Comment 8

[Boris Zbarsky [:bzbarsky]]

Why, exactly, was this marked duplicate?  I don't think this is related to bug 112738 unless I missed something.

Comment 9

[Boris Zbarsky [:bzbarsky]]

This bug needs triage for real.

Comment 10

[Wayne Mery (:wsmwk)]

knew I'd seen it somewhere else...duping