Closed Bug 477571 Opened 17 years ago Closed 16 years ago

Major memory leak in v3 - consumes over 1gig when left idle

Categories

(Firefox :: General, defect)

3.0 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: wislam, Unassigned)

Details

(Keywords: memory-leak, Whiteboard: closeme 2009-06-28)

Attachments

(1 file)

I'm sure this will be marked as a duplicate. Nonetheless, since version 3 was released, there's been a horrendous memory leak somewhere. Over time, such as over a period of a day or two days while the browser is idle, it consumes well over a gig of paging file / RAM, usually up to 1.5GB. I've tried a new profile. Version 3.0.6 was a slight improvement - the memory was idling under 100megs, but when I left it idle over the weekend, I noticed today (Monday morning), that once again it's jumped to over a gig. v3 is the worst in terms of memory - yet all the ads say it's the latest and greatest and the "smallest" memory footprint?! It's also the slowest browser I've ever come across, compared against Opera or even IE 7. This is always reproducible for me, since version 3 was released.
I can not reproduce the issue and most other people can't reproduce the issue. The new profile doesn't help if you have system wide extension installed by some applications (AVG, Norton, Fingerprint software)... Do you have any addons that appear in a new profile ? Do you have fingerprint software installed ? Do you have other steps to reproduce that could help because this report is going nowhere if nobody else can't reproduce this.
Good point. I said this would be marked as dup as I was expecting pretty much everyone else to be experiencing this issue. I don't have any antivirus software, nor fingerprint software installed. However, I do have several extensions which, in combination, may be producing this issue. * Firebug v1.3.0 * Flashblock v1.5.7.1 * HTML Validator v0.8.5.2 * HTTPFox - v0.8.2 * Screen Grab! - v0.95 * Session Manager - v0.6.3.2 * Wed Developer - v1.1.6 The only constant between all versions of Firefox 3 on my machine has been the HTML Validator, Firebug, and Web Developer. So perhaps they may be responsible? Sorry, I can't provide any steps to reproduce, as the only way the memory has shot up to over a gig of usage has been when Firefox was idle. I'll try removing all extensions and test over the next few days and will report back. Bug 458773 and bug 468403 may be related.
http://quality.mozilla.org/bug-writing-guidelines has some helpful mem leak info you may want to read.
Never expect that an issue can be reproduced by other people.We would notice such a big memory leak and many people would report it. I asked for fingerprint software because such software injects some binary stuff in our process to get the password function working and they are causing often memory leaks and make Firefox slow. Some extensions are also causing memory leaks due to bugs in the extensions.
Just a quick update... Disabled all extensions (i.e. removed from my profile) except Firebug, but still crashed twice after using 1.4gigs (first time), and 1.7gig over this weekend. Just removed Firebug too, so there should be nothing else except Firefox. Strangely, on the many occassions when Firefox crashed due to this memory issue, I've never been asked to report the crash - has "Quality Feedback Agent" / BreakPad been disabled? In fact, since I installed FF3, I've never seen it - why would that be? With Firebug removed too, I'll report back in about a week regarding memory usage.
firefox 3 uses breakpad instead of talkback. if it isn't working, you can follow the instructions here instead: https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
Crashed once again with no extensions / addons to Firefox, after consuming 1.7gigs of paging file. Thanks timeless for that link! I've got Visual Studio, so I managed to debug the crashing firefox.exe process with VS 2005 and after defining the symbols path, I managed to get a stack trace. See attachment 365633 [details]. Please let me know if this isn't enough, and I'll run through the correct debugging procedure using WinDbg. I also need to read up on those mem leak tools.
ok, that crash is because you ran out of memory and we don't handle running out of memory from c++ (new). 96k isn't an unreasonable size for a manifest http://mxr.mozilla.org/mozilla-central/source/xpcom/reflect/xptinfo/src/xptiManifest.cpp?mark=301-303#284 301 whole = new char[flen]; 302 if (!whole) 303 return nsnull; We could for this specific crash (which happens at 301) replace |new| w/ malloc, if we did that, then we'd reach 302 and not crash (in this function). But until we fix the general case for new(), it would only prolong your life until the next spot you hit (and there are quite a few including a number in the Cycle Collector used with GC)
This hasn't had an update for a while, so thought I should comment... Another weekend, another crash, with a warning saying: - "Visual C++ Runtime Library" "This application has requested the Runtime to terminate it in an unusual way." I've read the David Baron's article regarding memory leaks, and have been using leak gauge, but so far it hasn't found any leaks. Just wondering, how accurate are these tools? Is there any more I can do besides enabling the memory debug options for FF and using this tool? Also, I'm sure more people are encountering this as I've spoken to a few people in the office who have downgraded their version of Firefox to v2 after they came across the exact same issues - considerable memory usuage leading to crash after leaving PC on for a few days. I'll continue using Leak Gauge.
are you still running w/o extensions? also, please try disabling plugins (tools>addons>plugins>...). anyway, there are other tools, https://wiki.mozilla.org/Performance:Leak_Tools most of them require you not to crash, although if you crash and have logs it's possible to guess which objects are leaked. most of those tools require you to build your own gecko, but if you have visual studio, and are willing to follow instructions, it isn't that hard. note that windbg/visual studio can debug the runtime library dialog message, just attach w/ whichever and get a stack, that's probably an oom death too.
Quick update: leak guage still hasn't found anything, even when memory usage was at 1.5 gigs before closing FF normally (without crash). Disabled all plugins, except Moz default and Flash, but memory still shot up to 1.5gb before crash over the weekend. Using Flash version 9.0 r45, but used the same version with FF v2 without issues. Also tried downgrading to Flash v6, but still same issue.
Flash 9 is EOLd and 45 is almost certainly exploitable. you should be using flash 10. and you should try disabling *all* plugins, not just "everything but flash". and you haven't indicated if you've disabled all extensions (so I'm assuming you haven't) - please do.
flash v6 is ancient :) and also echo comment 13. Can you reproduce with FF beta* started in safe-mode and flash v10? * http://www.mozilla.com/en-US/firefox/all-beta.html
Whiteboard: closeme 2009-06-28
No reply, INCO. Please reopen if you still see this bug in Firefox 3.5 or later in Firefox safe mode (http://support.mozilla.com/en-US/kb/Safe+Mode) or a new Firefox profile (http://support.mozilla.com/en-US/kb/Profiles) with updated plugins.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
I have been experiencing these problems off and on since the update to 3.5 as well. mainly when I have multiple tabs open and leave them idle overnight. upon trying to re-open tabs, firefox hangs, and I have to abort the process tree. re-starting firefox brings me to the "oops, we can't open your last session, what do you want to do" screen, where I can restore my session. it seems that there's no particular webpage this hangs on or if it's my RSS feeds or addons, as I've experienced it without them as well...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: