Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Mozilla The Internet Software

Firefox Working to Fix Memory Leaks 555

Christopher Blanc writes "Many Mozilla community members, including both volunteers and Mozilla Corporation employees, have been helping to reduce Firefox's memory usage and fix memory leak bugs lately. Hopefully, the result of this effort will be that Firefox 3 uses less memory than Firefox 2 did, especially after it has been used for several hours." Here's hoping. Frequent restarts of things on my computer make me furious. I can't imagine why anyone would tolerate such things.
This discussion has been archived. No new comments can be posted.

Firefox Working to Fix Memory Leaks

Comments Filter:
  • Re:about time! (Score:2, Informative)

    by tritonman ( 998572 ) on Monday September 24, 2007 @12:33PM (#20730405)
    Half the time when I start having memory problems on my PC, I look at firefox (which is just has one tab open with yahoo mail) and it is using like 400 megs of RAM.
  • Try Opera (Score:0, Informative)

    by Anonymous Coward on Monday September 24, 2007 @12:34PM (#20730417)
    It runs well on your cellphone, Nintendo Wii/DS and pretty much anything else with a screen & network connection, So I think it's safe to assume it will work on your desktop.
  • by Gertlex ( 722812 ) on Monday September 24, 2007 @12:36PM (#20730455)

    Here's hoping. Frequent restarts of things on my computer make me furious. I can't imagine why anyone would tolerate such things.

    I tolerate it with an extension that provides a restart button on the toolbar. There are several such extensions. It's also useful for when one wants to quickly restart after installing/enabling/disabling an add-on/theme.

    And of course, said extensions reload Firefox with the windows/tabs you had open.
  • Re:Symmetry (Score:3, Informative)

    by Anonymous Coward on Monday September 24, 2007 @12:41PM (#20730537)
    LOL, maybe if you're working in a purely functional programming language :P if that were really the case, you could allocate everything on the stack. In practice, it's often necessary to keep stuff around in dynamically allocated memory between function calls, which is why we have the heap.
  • by SplatMan_DK ( 1035528 ) * on Monday September 24, 2007 @12:53PM (#20730737) Homepage Journal

    How is it that an open source project is taking this long to fix bugs such as this?
    Because knowing the symptoms is not the same as knowing how to fix the problem?

    Observing the existence of a memory leak, and knowing where to fix it in your code, are two VERY different things.

    - Jesper
  • Re:Symmetry (Score:3, Informative)

    by iabervon ( 1971 ) on Monday September 24, 2007 @12:55PM (#20730769) Homepage Journal
    The easiest way is to get the flashblock extension and some flash plugin, and never click on a flash thing. There's also some way to make a plugin registered for flash that does nothing.
  • Re:Symmetry (Score:3, Informative)

    by TemporalBeing ( 803363 ) <bm_witness@BOYSENyahoo.com minus berry> on Monday September 24, 2007 @01:05PM (#20730965) Homepage Journal

    Are there really any memory problems that cannot be cured by strict adherance to the rule of "allocate memory at the beginging of a routine, deallocate same amount at the end"?
    This would be better states as: "allocate memory when needed and dellocate when no longer required" - memory allocations/dellocations do not always occur in the same routine, and this only gets worse in OO programming. However, garbage-collection does not resolve the issue either. The real answer is smart design and smart programming - and by smart programming I am not talking about garbage-collectors, etc. done for the programmer, I am talking about programmers programming smartly so that their programs manage their resources properly and efficiently.

    Which brings my second point - even with your original version, this cannot always be done in some languages as some languages remove the ability to free resources. For example, so far as I am aware - and so far as I can tell - Java cannot free memory resources outside of the garbage collector [sun.com]. So much for a programmer being able to manage their resources properly - this is probably also one of the big reasons Java sucks at performance.
  • by Constantine XVI ( 880691 ) <trash,eighty+slashdot&gmail,com> on Monday September 24, 2007 @01:10PM (#20731037)
    Sorry, but quite a few other browsers (Opera, Konqueror, Safari(the WebKit part anyways)) are written in C++, and they don't seem to have near the problems Firefox has.
  • by www.sorehands.com ( 142825 ) on Monday September 24, 2007 @01:10PM (#20731041) Homepage
    It is because people accept poor programming as the norm. Oh, yeah, just reboot it and it'll be fine.

    I consult for someone who uses ACT! 2005. When they got the upgrade notice, they asked me to check it out. I spoke to ACT! support and they told me "We improved performance by releasing resources that we are no longer using." I said, "THAT IS A BUG FIX!" Anybody writing code outside of school should be doing it, and if I was grading their code, I would take points off for that.

    I'd like to see some of these software companies that do this get sued for such poor coding practices.
  • by jsebrech ( 525647 ) on Monday September 24, 2007 @01:15PM (#20731131)
    XUL is inherently single-threaded and JavaScript based. Try out any XUL application out there and you'll see how you get the same poor performance, speed and resource usage as with Firefox (try Miro Player and Joost). ...

    Actually I'm pretty sure they're in denial as to the cause of their problems. Announcing they're working on fixing "memory leaks" just supports their ability to continue their delusion.


    They're not in denial. They're working on tamarin [mozilla.org], a replacement/upgrade of their javascript engine based on the same engine that's in flash 9 / actionscript 3.

    Tamarin will run javascript 2, which will to do javascript what the move from actionscript 2 to 3 did for flash/flex. In short: it will make non-toy applications easily done, instead of just marginally feasible. They plan to migrate the firefox UI and extensions to javascript 2, which should negate the performance issues. Only problem: it won't be ready for FF3.
  • by jsebrech ( 525647 ) on Monday September 24, 2007 @01:29PM (#20731349)
    Today, FF has morphed in to something which can't be used, with plugins, for more than a couple days max without needing to be reset.

    You say that, and you compare it to IE. The only environment where I know people keep a firefox process open for days is on the mac, which doesn't run IE anymore (and btw, safari 2 leaks like a sieve too in my experience). Yes, I have to relaunch ff on my mac every few days. But on windows every time I close my last window, the browser shuts down and all memory is reclaimed. So, on platforms that are not mac, and for "normal" use patterns (i.e. don't leave a browser window with sites open for days), this is a non-issue.

    Thiis page may be informative about the issue of memory in firefox: http://plugindoc.mozdev.org/faqs/memusage.html [mozdev.org]
  • by Alien Being ( 18488 ) on Monday September 24, 2007 @01:37PM (#20731447)
    The biggest memory leak does not show up in firefox itself. It shows up in the X process:

                TIME+ PID USER CODE VIRT SWAP RES SHR S %CPU %MEM P COMMAND
          391:42.00 30262 root 1712 864m 481m 383m 5636 R 20.5 38.0 0 X :0 -auth /home/me/.serverauth.30245
            19:54.97 5473 me 9.9m 350m 202m 148m 18m S 0.0 14.7 0 firefox/firefox-bin

    xrestop shows this:

          res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier

          3600000 295 62 1 2664 119 621592K 12K 621604K ? Firefox Working to Fix Memory Leaks - Mozilla Firefox

    In other words, X has over 600MB of memory holding pixmaps for firefox. This grows every time I open a page/tab with images in it.

    Closing pages/tabs does not free the memory from X, nor does lowering firefox's various cache settings in the preferences dialog and about:config. Quiting firefox causes X to release the memory. I have to do this at least once a week.

  • by Futurepower(R) ( 558542 ) on Monday September 24, 2007 @01:39PM (#20731483) Homepage
    What people call the memory gobbling bug is actually also a CPU hogging bug, and it is still present in Firefox version 2.0.0.7, even though the bug was reported perhaps 5 years ago. Versions 2.0.0.7 and 2.0.0.6 are far more stable than previous versions, but Firefox is still the most unstable program in common use.

    The CPU hogging bug in Firefox may be caused by inadequate allocation of resources. Maybe the chaining of the event handler code with numerous windows open is an issue.

    Firefox crashes Microsoft Windows. Apparently there is a bug in Windows, or more than one, that causes the entire Microsoft Windows OS to become unstable when Firefox starts CPU hogging. In any case, the only way to get Windows back to a stable state after killing Firefox is to re-start the computer.

    It's interesting that Firefox can be used to show that Windows is an unstable OS, in some cases. Linux is completely stable; it is only necessary to kill Firefox to regain resources.

    The Firefox CPU hogging bug occurs only during heavy use of Firefox, with many Windows and tabs open for several hours, such as happens when someone in purchasing in a corporate environment is researching computer parts. The problem is made worse if the computer is hibernated or put in standby.

    If you open a lot of windows and tabs in Firefox on a laptop, and put the laptop in and out of standby, you will eventually notice that the laptop fan is running all the time, even when there is no activity. That's the CPU bug, and it can potentially shorten the life of your laptop. The fan is often the laptop component that fails first.

    It is interesting to note that the latest version of Opera also exhibits CPU hogging, but much less frequently. However, using Opera is not as comfortable because of poor design decisions in Opera.

    See: Firefox is the most unstable program in common use. [slashdot.org]

    Firefox developers apparently game the system by abusing those who report bugs: Mozilla Foundation Top 20 Excuses for Not Fixing Firefox Bugs [slashdot.org].

    Firefox development sometimes resembles playing. [slashdot.org]

    Basically, this seems to be the underlying problem: Winifred Mitchell Baker [wikipedia.org], the CEO [mozilla.com] of Mozilla, is a socially uncomfortable lawyer who became CEO when no one thought there was an opportunity. Now Mozilla Foundation is making millions from designating Google as the default search engine.

    Winifred has insufficient control over those who work for her, because she doesn't understand what they do. The Firefox CPU hogging and memory gobbling bug would take some serious troubleshooting to find, and no one wants to do the work, apparently.
  • by mce ( 509 ) on Monday September 24, 2007 @01:41PM (#20731511) Homepage Journal

    I agree with both of you. But I'd like to point out that Firefox has garbage collection mechanisms built-in, written in C++. But, as it turns out, garbage collection is not as simple to write as one might think and the presence of garbage collection support makes people lazy, also in C++. And of course, especially in C++ this is a Bad Thing (TM). Lazy programmers quickly start assuming that malloc() and strdup() are auto-collected as well.

    Garbage collection in C++ is especially tricky, actually, because a single forgotten pointer "at the broder of the collection scope" can prevent many megabytes of interlinked "garbage collected" data structures from being detected as a loop and hence collected for real. Everybody assumes that the whole thing will auto-die and writes code accordingly, allocating like hell and not caring about resources; nobody is aware of the fact that somewhere in one single file a pointer assignment might be missing that blows their collection dreams out of the water.

  • by ClosedSource ( 238333 ) on Monday September 24, 2007 @02:23PM (#20732153)
    A well-written C++ program is going to free memory much faster than a GC can. The value of GC is that you don't have to worry about forgetting to free memory, it will happen - eventually.
  • Memory leaks (Score:3, Informative)

    by Per Abrahamsen ( 1397 ) on Monday September 24, 2007 @02:25PM (#20732173) Homepage
    Real programmers can code memory leaks in any programming language.

    (I'm not kidding, it is very easy to accidentally use a strong pointer, where a weak pointer should have been used. Especially in languages that doesn't support the later concept :-)
  • by colfer ( 619105 ) on Monday September 24, 2007 @02:44PM (#20732525)
    Some valid points, but FF has a fix for the Hibernate bug, maybe more fixes coming, see Bug 213637 and its friends. That fix will be in 2.0.0.8, while 2.0.0.7 was an emergency release for the "Quicktime abuses Firefox command line parameters" vulnerability.
  • Evidence of denial. (Score:4, Informative)

    by Futurepower(R) ( 558542 ) on Monday September 24, 2007 @02:59PM (#20732815) Homepage
    "They're not in denial."

    Maybe Mozilla people are not in denial about that one technical issue, but they certainly have been about others. See Mozilla Foundation Top 20 Excuses for Not Fixing Firefox Bugs [slashdot.org], posted to the story 611 Defects, 71 Vulnerabilities Found In Firefox [slashdot.org].

    Since that Slashdot story, many many memory leaks have been found in Firefox which have made it much more stable. But Firefox is STILL the most unstable program in common use. [slashdot.org]
  • Re:About time (Score:3, Informative)

    by BZ ( 40346 ) on Monday September 24, 2007 @03:12PM (#20732995)
    > So have they finally acknowledged that Firefox is a memory hog instead of just blaming users

    I have yet to see an actual Firefox developer blame users for memory usage issues. Anyone actually working with the code knows that there are problems that need fixing.

    What I _have_ seen are fanboys who've never looked at the code making claims about what is or is not leaking without a basis in reality.

    The fact is:

    1) There are some leaks in Gecko
    2) There are some leaks in the Firefox UI
    3) There are some leaks in extensions
    4) There are some behaviors in all three that are not leaks but do
            lead to prolonged usage of large amounts of memory.

    By "leak" above I mean "memory not deallocated until program shutdown", which is a looser meaning than the typical meaning of "leak" as "memory the program does not deallocate at all". In the end, the user doesn't care which is happening.

    All four items above need to be addressed, though for item 4 there is the obvious question: is there utility from the user's point of view in holding on to that memory, and does that utility outweigh the memory usage. Put another way, a 5MB RAM page cache is clearly too small and a 500MB one is clearly too big (on modern hardware). The question is what a "good" size is.

    > The memory buffers use up 3/4 of my memory with an empty, just launched, instance of Firefox.

    You mean on Linux? A lot of that is disk buffering into RAM, right?

    > but maybe I'm wrong

    You're wrong.

    > allocating buffer memory without even a single page loaded

    To start a program you have to read it from disk. Linux in particular very aggressively buffers disk into RAM; it probably has not only all the files touched (not necessarily still open!) by Firefox as it starts, but various other programs you've started as well, the Firefox disk cache, etc, etc.
  • by Futurepower(R) ( 558542 ) on Monday September 24, 2007 @03:32PM (#20733343) Homepage
    I notice that some of the same old excuses are used here and in the comments to the article linked by the Slashdot article.

    As a community service, I'm posting this list I made. When someone wants to use one of the excuses, they can just give the excuse number. That will save typing.

    Mozilla Foundation Top 20 Excuses for Not Fixing the Firefox Memory and CPU Hogging bugs.
    1. Maybe this bug is fixed in the nightly build. [The same memory and CPU hogging bug has been reported many, many times over a period of five years.]
    2. Yes, this bug exists, but other things are more important. [The bug eventually takes 100% of CPU power, and makes Windows XP unusable, even after Firefox is killed. The bug affects the heaviest users of Firefox.]
    3. Yes, this bug exists, but it is not a common occurrence. [Numerous users have reported the bug. See the links.]
    4. Works for me. [The bug is complicated to reproduce, so the developers did a simplified test, which didn't show the bug.]
    5. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated. TalkBack does not generate a report if Firefox is hogging the CPU. TalkBack cannot generate a report if the bug takes 100% of the CPU time.]
    6. If you would just give us more information, we would fix this bug. [They didn't bother to reproduce the bug using the detailed information provided.]
    7. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
    8. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
    9. I don't like the way you worded your bug report. [So, he didn't read it or think about it.]
    10. You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.]
    11. Many bugs that are filed aren't important to 99.99% of the users.
    12. If you are saying bad things about Mozilla and Firefox, you must be trolling. [They say this even though Firefox and Mozilla instability is beginning to be reported in media such as Information Week. See the links to magazine articles in this Slashdot comment: Firefox is the most unstable program in common use [slashdot.org].]
    13. Your problem is probably caused by using extensions. [These are extensions advertised on the Firefox and Mozilla web site, and recommended.]
    14. Your problem is probably caused by a corrupt profile. [The same bug has been reported many times over a period of five years. One of the reports discusses an extensive test in both Linux and Windows that used a completely clean installation of the operating systems, not just a clean profile. The CPU hogging bug and instability was just as severe.]
    15. If you are technically knowledgeable, you can spend several hours (or days) trying to discover the problem: Standard diagnostic - Firefox [mozillazine.org] [mozillazine.org]. [Firefox has "Standard Diagnostics". It has become accepted that some users will have severe problems. !!! ]
    16. I won't actually read the (many) bug reports, but I will give you some complicated technical speculation. [This pretends to be helpful but, on investigation, is shown to have nothing to do with the bugs.
    17. It's understandable that Firefox developers become defensive when users report so many problems.
    18. To spend smart developers' time going over reports of bugs generated by analysis tools would be a waste. [There have been 3 analysis tools recently used to find Firefox bugs, and many have been found: 1) A special tool designed by a Firefox developer. 2) Software by Coverity. 3) Klocwork's K7.]
    19. Your bug report was not specifi
  • Re:Not insane. (Score:3, Informative)

    by HeroreV ( 869368 ) on Monday September 24, 2007 @08:24PM (#20736957) Homepage
    Firefox already has a garbage collector for detecting memory leaks. (It's only used for debugging.) Of course, it probably doesn't help much when JavaScript objects create circular references with C++ XPCOM components, which are reference counted. Those circular references are the main source of memory leaks (or object leaks?) for Firefox. It's very easy to create them, and many extensions are very bad about creating lots of them.
  • by Anonymous Coward on Monday September 24, 2007 @11:27PM (#20738279)
    Congratulations! You didn't read the fucking article.

    The very first optimisation they discuss is: "Federico Mena-Quintero submitted a patch to make Firefox discard decompressed image data after five seconds (bug 296818)"

    Click the link in the article - it leads to discussion about how X is holding all this image data for Firefox and how it's been fixed to not do that any more.
  • by Anonymous Coward on Tuesday September 25, 2007 @04:37AM (#20740249)
    And many people seem to forget that a GC-backed system CAN also LEAK memory. This can happen easily when a programmer forgets to throw away references to certain objects. (For example, when lots of objects are stored in a large table, and are subsequently forgotten, but the table is still referenced.)

Old programmers never die, they just hit account block limit.

Working...