Closed Bug 261783 Opened 20 years ago Closed 19 years ago

Malformed HTML causes memory leak and eventual crash

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: DaveHowe, Unassigned)

References

(
URL
)

Details

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 http://www.panix.com/~jdev/cclock.cgi
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:
http://lcamtuf.coredump.cx/mangleme/gallery/

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:
http://www.securityfocus.com/archive/1/378632/2004-10-15/2004-10-21/0
It also suggests the attack may be exploitable.
Assignee: mitchell → general
Component: Miscellaneous → Browser-General
Product: mozilla.org → Browser
QA Contact: mitchell → general
Version: other → Trunk
Product: Browser → Seamonkey
I opened the site http://www.panix.com/~jdev/cclock.cgi 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
Firefox/1.0+

The three crash examples at:
http://lcamtuf.coredump.cx/mangleme/gallery/
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.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20050110
Firefox/1.0+

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 
http://www.howtocreate.co.uk/tutorials/jsexamples/anclock.html ,
but this also consumes a lot of CPU cycles
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)
Product: Mozilla Application Suite → Firefox
Well, I'm marking this bug WORKSFORME. If anyone can still reproduce this bug in
the nightly builds (
http://ftp.scarlet.be/pub/mozilla.org/firefox/nightly/latest-trunk/ ), then
please reopen.
Please file a new bug if you see an issue that doesn't have anything to do with
this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.