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
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)
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 ( 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
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.