Firefox memory leak with large html files with tag errors

Bug #304942 reported by spbike on 2008-12-03
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Firefox
firefox-3.0 (Ubuntu)

Bug Description

Binary package hint: firefox-3.0

mv .mozilla .mozilla-backup # insure it's a vanilla firefox config on intrepid

Go to this url

Run top (sort by memory if you wish with M). Watch it rocket to:
Mem: 2070924k total, 1671048k used, 399876k free, 20800k buffers
Swap: 2586424k total, 156176k used, 2430248k free, 278644k cached

 3820 bill 20 0 1122m 1.0g 21m S 3 51.0 2:22.96 firefox

The page has just 20-30 lines of normal looking HTML, and a large (10-20 screens) page of text inside a <pre>.

My system is currently patched and:
lsb_release -rd
Description: Ubuntu 8.10
Release: 8.10

And firefox:
  Installed: 3.0.4+nobinonly-0ubuntu0.8.10.1
  Candidate: 3.0.4+nobinonly-0ubuntu0.8.10.1
  Version table:
 *** 3.0.4+nobinonly-0ubuntu0.8.10.1 0
        500 intrepid-updates/main Packages
        500 intrepid-security/main Packages
        100 /var/lib/dpkg/status
     3.0.3+nobinonly-0ubuntu2 0
        500 intrepid/main Packages

I'd expect a page with 10 screens of text to take alot less than 1GB of ram.

spbike (bill-broadley) wrote :

I forgot to mention the memory use does flatten at 1.2GB.

I can reproduce this with Firefox 3.0.4

2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

goto (gotolaunchpad) wrote :

I confirm it, too. Uses 1.9 GB (but a few more tabs open).
2.6.27-10-generic #1 SMP Fri Nov 21 19:19:18 UTC 2008 x86_64 GNU/Linux

Changed in firefox-3.0:
status: New → Confirmed
Richard Seguin (sectech) wrote :

Looking into the HTML file now... a wget shows that the .txt file is actually roughly 5MB

Changed in firefox-3.0:
importance: Undecided → Medium
Richard Seguin (sectech) wrote :

HTML file isn't even proper HTML... Firefox seems to be trying to process a 5MB broken HTML file which is probably why it spikes in resources...

* Flagging as low as it seems firefox is actually processing the HTML file (which is actually labelled as .txt)...

Changed in firefox-3.0:
importance: Medium → Low

Just ran the URI through the w3 validator:

Result: 4348 Errors, 479 warning(s)

Markus Edholm (markusedholm) wrote :

I created a similar file.. a short intro and a <pre> section of roughly 4MB plain text.. firefox struggles for a second (understandable for such a large file) but then displays it fine..

Great.... now we just need to determine if this is a bug with firefox or if
firefox is doing it's job and trying to process the file.

On Wed, Dec 3, 2008 at 6:48 PM, LumpyCustard <<email address hidden>
> wrote:

> Just ran the URI through the w3 validator:
> Result: 4348 Errors, 479 warning(s)
> --
> Firefox explodes to 1.2GB on simple URL.
> You received this bug notification because you are a direct subscriber
> of the bug.

I fixed the missing </body> and </html> with no change in memory use.. 4348 errors is impressive, although even this launchpad page has 50 some errors.

Richard Seguin (sectech) wrote :

There is a little more then meets the eye on this one... Once the file is completly loaded... I have firefox having a memory usage of 1GB... and it doesn't release the memory even when you navigate off that page.

Richard Seguin (sectech) wrote :

* Flagging importance back to medium

Changed in firefox-3.0:
importance: Low → Medium
spbike (bill-broadley) wrote :

I changed the <pre> to <xmp> and it's fixed. <pre> doesn't prevent HTML tags from working, <XMP> does which seems to be the intent. Looks like OCR mistakes put some random <b and the like, and firefox is likely trying to parse what looks like a 100k line tag.

So I don't think ti's a bug anymore.

Richard Seguin (sectech) wrote :

The issue that I still have with it is that even with incorrect html firefox shouldn't grab 1GB and hold it until exit... I want to look into this a bit more before a decision can be made on if it's valid or not.

spbike (bill-broadley) wrote :

BTW, I can verify that on intrepid if you allocate 256MB, then free 256MB that the OS immediately reclaims the memory and doesn't wait till exit. I believe the hold on to memory until exit was a property of older linux systems. I don't know enough about firefox's data structures to know if this is a bug.

Richard Seguin (sectech) wrote :

This doesn't help much.. but this is the result of the valgrind

Richard Seguin (sectech) wrote :

After consulting with a mozilla team member it has been determined that the bug is valid, but is a low priority as there are many ways of getting firefox to cause this... Leaving it as such...

Changed in firefox-3.0:
importance: Medium → Low

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008111318 Ubuntu/8.10 (intrepid) Firefox/3.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008111318 Ubuntu/8.10 (intrepid) Firefox/3.0.4

Do not load if you aren't ready for firefox to hit 1.2GB.

To replicate:
mv .mozilla .mozilla-backup # insure it's a vanilla firefox config

Go to this url

At least on ubuntu intrepid firefox process will increase to 1.2GB or so.

You should get a 4.9MB file, with a big block of <pre>. It looks like OCR'd text and there happens to be a <b in it. Replacing <pre> with <xmp> fixes it.

The missing </html> and </body> seem to have no effect, behavior does not change when I add them.

So basically I think firefox is trying to handle a <b ... > tag that is 100k lines long or something. In any case this results in an unusable browser on any system with <= 1GB ram. Even on a 2GB ram system it takes a few minutes of a non-responsive firefox to recover.

Reproducible: Always

Steps to Reproduce:
1. mv .mozilla .mozilla.backup # insure vanilla install

Actual Results:
Firefox downloads a 4.9MB page and expands to a process size of 1.2GB.

Expected Results:
Process should not increase to 1.2GB, something like 100MB or less would be much more reasonable.

I opened bug on ubuntu as well:

I spoke to the folks on #firefox, a few confirmed that they saw the same problem and after some discussion and bug searching they said I should post it:

This might be a regression, needs testing against Firefox 2, it's certainly behind in performance compared to other browsers.

Also seeing this in Vista HP SP1 using the latest trunk builds:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20081203 Minefield/3.2a1pre Firefox/3.0.4 ID:20081203114922

Changed in firefox:
status: Unknown → Confirmed

most likely dupe of bug 330029 or some other memory DoS

Alexander Sack (asac) wrote :

this isnt a tag open/close issue i guess. it happens also with just the <pre> LONG TEXT </pre>

fwiw, there ar eplenty of such memory exhaustion issues filed upstream. A good one would have been i guess.

Changed in firefox-3.0:
status: Confirmed → Triaged

Not a regressions.

Alexander Sack: The bug still occurs with Javascript disabled, is that expected?

bug 330029 is a DoS based on javascript, this bug is triggered on a page
without javascript.

spbike (bill-broadley) wrote :

If I fix the embedded "<" in the pre tag the bug goes away, total browser memory hangs around 98MB.

330029 is related to javascript, there is no javascript on this page.

o.k, my mistake, I assumed it was the large text on the file because opening text files of such magnitude causes memory size to balloon as well, but not quite of the same magnitude.

Changed in firefox:
importance: Unknown → Medium
Changed in firefox:
status: Confirmed → Unknown
Changed in firefox:
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.