Malformed HTML causes memory leak and eventual crash




14 years ago
13 years ago


(Reporter: Dave Howe, Unassigned)


Windows 2000

Firefox Tracking Flags

(Not tracked)





14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

CGI at site - sends a stream of <html>---content--</html> mini-documents to
achieve updating display (as does the iplanet server admin tool on Tru64, as of
the last release I used). It appears Firefox is not releasing the memory used
each minipage, and evenually consuming all ram.

Reproducible: Always
Steps to Reproduce:
1. Visit
2. Wait

Actual Results:  
Memory consumption and eventual crash

Expected Results:  
Discarded each "old" page when the new one is rendered
There are 3 examples of web pages that will cause Firefox 1.0PR to crash at:

Comment 2

14 years ago
I can confirm mozilla_die1.htm on the above site crashes Mozilla/5.0 (X11; U;
Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 on linux (gentoo). 
The relevant bugtraq page is here:
It also suggests the attack may be exploitable.


14 years ago
Assignee: mitchell → general
Component: Miscellaneous → Browser-General
Product: → Browser
QA Contact: mitchell → general
Version: other → Trunk
Product: Browser → Seamonkey
I opened the site in Firefox 1.0 and the
main thing I noticed was that it consumes a lot of CPU time.  Other than that I
let it sit for a few minutes and the amount of memory went up slightly by about
30 KB in that entire time.  Most of the time the amount of RAM used remained
constant.  All 30 KB were released when the tab was closed.

So if there is a memory leak it is too slow to be noticed in the short test I ran.
I don't see any memory leak happening, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050104

The three crash examples at:
also seem not to crash anymore in that build. 
The last example is freezing my build, though, but that is probably because of
the many nested marquees.

Comment 5

13 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20050110

Didn't crash for me, but the behaviour complained of is still in.

Viewing page source will show the problem.

OT If you want a clock on your web page, take a look at ,
but this also consumes a lot of CPU cycles

Comment 6

13 years ago
A few points to note:

* I cannot reproduce the reported memory usage increase or crashes in recent
trunk builds (on GNU/Linux).
* Although this apparently crashes according to reporter, I don't see it being
much of a security issue, so it will most likely not be fixed/backported to firefox.
* The content type from the URL is multipart/x-mixed-replace, which is causing
view->source to show nothing. I suppose this is a bug, but I'm not sure it's
worth fixing.

(changing component to Firefox, it has nothing to do with suite afaics)
Component: General → General
Product: Mozilla Application Suite → Firefox
Well, I'm marking this bug WORKSFORME. If anyone can still reproduce this bug in
the nightly builds ( ), then
please reopen.
Please file a new bug if you see an issue that doesn't have anything to do with
this bug.
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.