Firefox memory leak with large html files with tag errors

[spbike]

Binary package hint: firefox-3.0

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

Go to this url
http://www.archive.org/stream/titlelistofdocum024685mbp/titlelistofdocum024685mbp_djvu.txt

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

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 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:
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 http://mirror.cse.ucdavis.edu intrepid-updates/main Packages
        500 http://mirror.cse.ucdavis.edu intrepid-security/main Packages
        100 /var/lib/dpkg/status
     3.0.3+nobinonly-0ubuntu2 0
        500 http://mirror.cse.ucdavis.edu intrepid/main Packages

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

[spbike (bill-broadley)]

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

[Michael Phillips (michael-j-phillips)]

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)]

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

[Richard Seguin (sectech)]

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

[Richard Seguin (sectech)]

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)...

[LumpyCustard (orangelumpycustard)]

Just ran the URI through the w3 validator:

Result: 4348 Errors, 479 warning(s)

[Markus Edholm (markusedholm)]

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..

[Richard Seguin (sectech)]

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.
> https://bugs.launchpad.net/bugs/304942
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[spbike (bill-broadley)]

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)]

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)]

* Flagging importance back to medium

[spbike (bill-broadley)]

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)]

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)]

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)]

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

[Richard Seguin (sectech)]

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...

[spbike (bill-broadley)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.10 (intrepid) Firefox/3.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) 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
http://www.archive.org/stream/titlelistofdocum024685mbp/titlelistofdocum024685mbp_djvu.txt

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
2. http://www.archive.org/stream/titlelistofdocum024685mbp/titlelistofdocum024685mbp_djvu.txt

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:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/304942

[spbike (bill-broadley)]

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:

https://bugzilla.mozilla.org/show_bug.cgi?id=467846

[Zurtex (zurtex)]

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

[Jmjeffery (jmjeffery)]

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

[Alexander Sack (asac)]

most likely dupe of bug 330029 or some other memory DoS

[Alexander Sack (asac)]

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 https://bugzilla.mozilla.org/show_bug.cgi?id=330029 i guess.

[Zurtex (zurtex)]

Not a regressions.

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

[spbike (bill-broadley)]

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

[spbike (bill-broadley)]

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.

[Zurtex (zurtex)]

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.