Slashdot Log In
Firefox Working to Fix Memory Leaks
Posted by
CmdrTaco
on Mon Sep 24, 2007 11:29 AM
from the important-but-boring-work dept.
from the important-but-boring-work dept.
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.
Related Stories
[+]
Your Rights Online: Firefox 3 Antiphishing Sends Your URLs To Google 296 comments
iritant writes "As we were discussing, Gran Paradiso — the latest version of Firefox — is nearing release. Gran Paradiso includes a form of malware protection that checks every URL against a known list of sites. It does so by sending each URL to Google. In other words, if people enable this feature, they get some malware protection, and Google gets a wealth of information about which sites are popular (or, for that matter, which sites should be checked for malware). Fair deal? Not to worry — the feature is disabled by default."
This discussion has been archived.
No new comments can be posted.
Firefox Working to Fix Memory Leaks
|
Log In/Create an Account
| Top
| 555 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
about time! (Score:4, Insightful)
The memory bug is also a CPU hogging bug. (Score:5, Informative)
(http://www.futurepower.net/)
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.
Another person talks about Mozilla "denial". (Score:5, Interesting)
(http://www.futurepower.net/)
See this +5 comment posted below: Firefox's problem is architectural and not one of garbage collection. [slashdot.org].
Quote: 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. [my emphasis]
A +4 comment to that comment discusses Firefox's "four separate memory allocation schemes":
"1. Custom malloc/free implementation. (Yes, custom - not from libc.)
2. C++ new/delete operators, which for all I know may be overridden to use their malloc/free.
3. One of the first two with reference counting to decide when to free/delete.
4. JavaScript mark-and-sweep GC.
Dealing with this causes some truly insane hacks..."
Then read the comment they don't want you to see: The memory bug is also a CPU hogging bug. [slashdot.org] At present, it is marked -1 Flamebait. However, that comment begins to discuss apparent social problems at the Mozilla Foundation, and some of the same material has been marked +5 in the past.
Because YOU allow it! (Score:4, Informative)
(http://www.barbieslapp.com/)
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.
Re:C++ long-in-the-tooth? (Score:5, Funny)
(http://obsessivemathsfreak.org/ | Last Journal: Friday June 09 2006, @08:15PM)
Re:C++ long-in-the-tooth? (Score:5, Insightful)
(http://slashdot.org/)
Or perhaps they're too busy thinking about clearly-defined objects, robust interfaces, clean documentation and the "big picture" then to worry about moving individual bytes around.
Likewise, I don't trust any artist using Flash today. They should clearly know how to code, in assembly, animation and transitions. Use of a timeline is for losers. The creative process should always be sacrificed for knowing the code inside out.
Re:C++ long-in-the-tooth? (Score:4, Insightful)
Actually, I'd say they're not busy enough- if they actually had been, proper memory management should simply fall into place on top of a clean architecture. If you're trying to shoehorn memory management back into something that didn't support it before, you're going to have issues- and this applies whether you're doing c/c++ style management, reference counting, or garbage collecting.
Re:C++ long-in-the-tooth? (Score:5, Insightful)
C++ yields superior performance and memory usage, than higher level languages, in the hands of a skilled C++ programmer and it can lead to bloatware in the hands of a novice.
There is this old saying about blaming your tools for a poor job and it applies to software development too.
]{
Re:C++ long-in-the-tooth? (Score:4, Insightful)
Precisely. A skilled craftsman does not blame the tools. A skilled craftsman does the job right, and if it cannot be done right with the tools at hand, he/she goes and gets tools that are appropriate for the job.
Poor programming is possible in any language, and garbage-collected languages are no exception. I would also caution that garbage-collected languages tend to encourage more novice programmers because of the apparent ease of use (it isn't really easier). This results in a larger number of poorly-written apps by people who think they know how to write software. Taking away the need to explicitly manage memory just encourages lazy programmers who can always find something else to be sloppy about.
As for garbage collection making this sort of thing magically go away, that simply isn't the case. Working around garbage collection with things like "soft references" is a disgusting hack and is actually far harder than simply doing explicit memory management in the first place. Anyone who says differently has never had to manage any complex data structures that reference each other in non-trivial ways. The alternative is to basically write your own code that explicitly walks the data structure, deleting circular references, etc. If you're going to that much trouble, you are doing just as much work as you would for explicit memory management, but without the performance benefits from actually being able to destroy the objects immediately, and thus garbage collection is just hurting performance without providing any real benefit.
Basically, apart from the really trivial cases (most of which could be solved just as easily by simply creating a stack-local auto-destroy variant of malloc), garbage collection causes more problems than it solves. In my book, garbage collection in programming language ranks right up there with multiple inheritance as one of the worst ideas ever conceived.
Re:C++ long-in-the-tooth? (Score:5, Insightful)
(Last Journal: Monday November 28 2005, @12:21PM)
That's a good instinct. Never trust anyone using Flash.
Re:C++ long-in-the-tooth? (Score:5, Interesting)
Firefox's problem is architectural and not one of garbage collection.
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).
The Firefox developers are literally throwing out more C code with every release, replacing it with JavaScript code.
Leaks (in the classical sense) aren't what's causing Firefox's abysmal performance, and this is why Firefox 2 performs worse than Firefox 1.5, despite one of the "features" of Firefox 2 was supposedly plenty of fixed memory leaks.
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.
Mod parent up (Score:5, Insightful)
1. Custom malloc/free implementation. (Yes, custom - not from libc.)
2. C++ new/delete operators, which for all I know may be overridden to use their malloc/free.
3. One of the first two with reference counting to decide when to free/delete.
4. JavaScript mark-and-sweep GC.
Dealing with this causes some truly insane hacks, like the absolutely insane DOM C++/JavaScript implementation. (They're C++ objects, exposed as JavaScript objects, using something that's like XPCOM but isn't due to the overhead XPCOM imposes. I really don't understand it.)
Ultimately, though, it's worse than all that. All this crap leaves the code completely opaque, and actively prevents contributors from contributing code without having to learn an insane amount of infrastructure decisions.
It makes a project that's supposed to be open source effectively closed off to only the "official" developers: almost open source in name only.
Re:Mod parent up (Score:5, Interesting)
(http://web.mit.edu/bzbarsky/www/)
Uh... No. There are some arena allocators in use in the codebase for very specific tasks, but there is no custom malloc/free.
> They're C++ objects, exposed as JavaScript objects, using something that's like XPCOM but isn't
Actually, to be exposed to JS in Gecko something more or less has to be an XPCOM object at the moment. Then the XPConnect layer handles the glue between JS and C++.
> It makes a project that's supposed to be open source effectively closed off to only the
> "official" developers
As someone who got into this project without being in any way "official", I beg to differ!
Re:C++ long-in-the-tooth? (Score:5, Informative)
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.
Evidence of denial. (Score:4, Informative)
(http://www.futurepower.net/)
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:C++ long-in-the-tooth? (Score:5, Insightful)
Your argument is nonsense. If what you said held true, large scale applications should be able to be written is assembler. Without high level tools it wouldn't be feasible to create applications the scale we do today.
Wrong. What he is saying is that people who choose to use C/C++ for their applications should be competent enough to properly handle their own allocation and de-allocation of memory. If your abilities as a programmer preclude you from properly managing your application's memory then you need to look at alternatives that will take care of that for you.
There are plenty of languages out there that offer things like garbage collection. Developers need to make better choices about which tools they use to meet their needs, and also understand their limitations and work within those parameters.
dude.
Re:C++ long-in-the-tooth? (Score:4, Insightful)
Statements like this are why I prefer Java programs to C ones. Mandatory bounds checking means that no macho idiot can turn it off, no matter how full of hubris he is. But even assuming a 100% perfect coder, does it really make sense to use his precious time to worry about memory management when the computer can do that automagically ?
Re:C++ long-in-the-tooth? (Score:4, Insightful)
Frankly if you can't look at a problem and then pull out five or six languages from your tool belt and evaluate which will be the best for this job, then you are a bad programmer. Don't code in C++ that which could easily be done in Python. Don't code in Python that which could easily be done in Bash. If you don't have a compelling argument for using C, DON'T USE IT!
Sometimes I think Java is awful for no other reason than companies tend to believe that using one language for other is a net gain. That has never been my experience except when your very best programmers aren't all that good either. If you insist that everything run on the Java runtime, use Jython and embed Python. A good example of multi-language gains can be seen with embedded Lua. There are many applications out there that use Lua "under the covers" so that things that do not have to be written in C++ aren't. This includes games (I believe WoW is one).
Re:C++ long-in-the-tooth? (Score:4, Insightful)
(http://slashdot.org/ | Last Journal: Thursday April 12 2007, @09:41AM)
While I agree with this sentiment on principle, in practice this has proven to yield unworkable solutions. Different people bring different skillsets to the table. You may have a dozen developers who all have C++ in common, but to varying degrees. One may be more skilled in Perl, another in smalltalk, another in Python, and three more in Java. Divvy up the specs and tell each one to "Write your code using the best tool for the job." Then spend another year trying to integrate the pieces, and when they quit try to hire someone who can maintain the hydra.
Picking a single language for a project (at least at the component level) is pretty much a requirement.
Even though they try to hand-wave it away, this has been a big problem in the Microsoft .NET world. When it was introduced, Microsoft promised that all .NET languages were equal, first-class languages (my interpretation at the time was that C# programmers were instantly demoted to VB programmers :-( ) and that a developer could write in whichever .NET language they were most comfortable. But there are C# programmers and VB.NET programmers who don't really speak each other's language, even though they all compile down to the same MSIL. Trying to get them to maintain each others code leads to a lot of squabbling.
It's easy to say "A good programmer can write in any of these languages" but in reality it's much harder to find a lot of good programmers that are both willing and able to competently do maintenance in all of the languages you might end up with.
Re:C++ long-in-the-tooth? (Score:5, Insightful)
(http://clocksmind.blogspot.com/ | Last Journal: Sunday February 25 2007, @05:09PM)
C/C++ and similar languages, on the other hand, force the programmers to manage their resources. In those cases, the programmers would likely be just not designing their programs well, or employing bad resource management. Yes, managing resources can be hard - one project I worked on had to go through several months of testing to get the resources properly managed, and even then some of the resources were still a little uncontrollable due to legacy code or Windows APIs, but overall the thing was pretty stable and any memory leaks were mostly due to Windows APIs.
In either case, I can't tell you how many times I have heard (especially from Java programmers) something along the lines of the following: "RAM is cheap", "processors are getting faster", "computers will be ready for this when we deliver it", "hardware is cheaper than programmers"
No offense, but to rely on hardware always being getting faster, or the cost of adding more RAM always being cheaper, etc. is a bad premise to rely on. Already with multi-core processors we are seeing slower processors being combined into a single processor get the equivalent processing power of a faster processor (e.g. two 1.8 Ghz cores rated equally to a single 3 Ghz core); thus the premise breaks down. Also, I want to be able to do more with the faster processors and additional RAM, rather than simply do the same job I could do yesterday only in "better" software.
The real answer is doing your job right, and using the right tool - which is not necessarily the easiest tool to use either. We also need to get back to writing applications that have good, if not great, performance with minimal resource requirements (e.g. RAM and processor). If we're not going this at the API/library level - at the very least - then the programs and library/APIs that rely on that API/library level will have worse performance no matter what they do. But in either case it doesn't get done unless the programmers do their job, and use tools that allow them to do it.
Re:C++ long-in-the-tooth? (Score:4, Insightful)
(http://tsfraser.googlepages.com/index.html)
I Agree with you the Duel Cores are not equal to systems with twice the GigaHertz and the singlecore twice as fast system normally will out preform the application written. But that isn't about C++ Program or Java Programming, It is about Multi-Threaded programming. Parallel processing is a different form of programming that most programmers shy away from. But still the fact if you are paying a programmer $20 and hour and it takes them twice as long to get a 10% increase in speed it would be better off buying extra RAM then paying the programmer.
Now if you are getting a boxed application that is different because the cost of application development programming is spread across all the people who buy it. So by Doubling the price of the Shrink Wrapped App. say from $80 to $160 and everyone gets a 10% increase in speed then it is worth it to put the extra in and get it more optimized, the degree of benefit will outweigh the costs.
The thing that usually gets me like comments like this parent it assumes a completely Academic Computer Science approach to all problems. While real life requires making trade offs and sacrificing performance is often a good trade off to make because most of the time it is unnoticeable, most computers spend most of their time idle anyways, and most application are idle waiting for inputs. So in the once in a while heavy processing moment say in this case an HTML Render adding 1 second to the load in real life most people wont notice unless they are going back and forward button crazy. Or doing a batch rendering job. As for memory I am surprised that you didn't bring up the large quanity of 32bit systems still out there being sold as new only handling a max of 4 GB or RAM so for a large population RAM limits are an issue again.
java memory profile (Score:5, Interesting)
(Last Journal: Monday February 03 2003, @08:59PM)
> etc. as they tend to have lazier programmers
Actually, it isn't lazier programmers. The problem is that existing garbage collection implementations have horrible memory profile.
If you look at the memory usage of a java program, it's about as bad as a c program that does nothing but leak memory. Practically speaking, java does little to free memory until it has *run out of memory*. Then when it does run out of memory and it needs to clean things up, things get slow as hell.
>The real answer is doing your job right, and using the right tool - which is not necessarily
>the easiest tool to use either.
Yes! Unfortunately, academics and many novice programmers (who just got finished being trained by academics) are unfamiliar with the powerful tools available like C++. Going to school can give you the mistaken impression that garbage collection is *a good thing* because everyone uses it there. The truth is that C++ is a very complicated language with a steep learning curve, but that many times it is simply the only tool that is suitable for the job.
If your program is IO bound, like a web application front end, you are in a great position, because essentially *any* tool will do the job, even if the performance is abysmal. You can use java, ruby, or whatever. And you should, becuase those languages don't present you with the complexity of c++.
Unfortunately, many programs *are not IO bound* and the performance and memory profile of the underlying tool are very important. This is most true of interactive non parializable programs. So, a good example would be bittorrent programs. Consider utorrent vs azureas, one in c++ and one in java. utorrent is fairly light weight and easy to use because of its performance characteristics. Azureus is a powerful and well engineered program, but it sure as hell is slow and chews up memory.
Re:C++ long-in-the-tooth? (Score:4, Informative)
Automatically != Efficiently (Score:5, Informative)
Bloat in general (Score:5, Insightful)
(http://www.vhemt.org/)
Yay! (Score:1)
but but (Score:5, Interesting)
Re:but but (Score:5, Interesting)
(http://www.foobarsoft.com/)
I've heard that too. I use FF on my desktop at work with one or two plugins (FlashBlock and FireBug, mostly). It does leak memory after enough time. Closing the browser always fixes it, so it's not much of a problem.
That said, if a plugin leaks memory, there are a few options. First, the system should know. Even if the plugin in used constantly, I should be able to open the extensions options panel and see how much memory each one is using, so I can identify the culprit. There should be a warning system ("Plug-in 'MemHog2' is using 500MB of ram, close/ignore/disable?").
Also, when a plugin isn't in use, then it shouldn't cause a problem. Let's say that the problem is Flashblock. If it isn't actively rendering (say I only have one window/tab open and it's pure text, no flash/etc) then it really shouldn't be using any memory. If I have FireBug inactive it should use next to no memory (when I have it actively checked CSS/JS/etc I expect it to use memory).
I'm glad they are working on this. I've heard this complaint for a while. But even if the problem is the plugins, it needs fixing or roping in.
How about being able to set memory limits for plug-ins, Mac OS 1-9.x style? Maybe total, maybe per active page, maybe both. Just a random idea.
Firefox != Internet (Score:5, Insightful)
(http://datanytt.no/)
Nobody forces you to use Firefox. You can use Opera, Konqueror, links or IE, or any other browser out there...
Re:Firefox != Internet (Score:4, Interesting)
Firefox was supposed to be able to withstand popularity, unlike IE. Look at it now: people say it's slow, RAM hog, and hackers have started attacking it successfully just as much as IE.
At least we see it for what it is: the stick in Microsoft's eye that made them resume IE development.
too litlle too late (Score:3, Insightful)
(http://www.footballfans.tv/)
Re:too litlle too late (Score:4, Insightful)
Symmetry (Score:2, Interesting)
(http://members.virtualtourist.com/m/51ebe/ | Last Journal: Monday August 20, @09:15PM)
Re:Symmetry (Score:5, Funny)
I think the problem's in the details...
Re:Symmetry (Score:5, Funny)
(http://www.ucblockhead.org/journal/ | Last Journal: Thursday November 14 2002, @03:24PM)
Kinda hard to code like that, though.
Re:Symmetry (Score:5, Funny)
(http://stinerman.livejournal.com/)
It's enough to make anyone consider using IE... (Score:1, Redundant)
I know. It's enough to make anyone consider using IE...
Restart your *computer*? (Score:1)
(Last Journal: Friday May 21 2004, @12:42PM)
Frequent restarts of things on my computer make me furious
Shit Taco, what OS are you using? FF leaks on my OS X box too over time, but quitting the app seems to free up the memory.
Or maybe I'm not paying close enough attention.
Restarting Isn't much of a problem (Score:5, Informative)
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.
Surprise search engine choice! (Score:1, Offtopic)
(http://operagost.com/ | Last Journal: Monday May 01 2006, @12:08PM)
You're already tolerating it by using it at all... (Score:5, Insightful)
(http://www.matchorclash.com/)
Well, my guess is that you *are* tolerating it, as are millions of others, simply because you're using it (either older versions of IE, or current versions of Firefox). Can't comment on IE7 cause I don't use it much, but IE6 rarely crashed for me. IE3-5.5, almost daily crashes.
5 years ago people people would constantly belittle IE users because it had frequent crashes, and pointed to the 'superior' Mozilla suite. 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. I add the caveat in there about 'with plugins' because I'm not sure I know many people who run a bare-metal Firefox. Most people use one or more extensions. This has been a huge marketing push for FF - "It's lean! Only use what you need! Get rid of 'bloat' - package everything in extensions!"
Putting things in extensions makes the base 'leaner' but has lead to a situation where there's no centralized testing for, or even acknowledgement of, memory leak bugs (and other bugs, but this is the obvious one). I still read comments from people who claim they never have leaks with FF (we'll see some on this thread no doubt). It's not that I don't believe them, but their usage patterns are likely different from mine. I have about 6 plugins that I love to use, and I like to keep my browser going. The idea that MSIE is more "stable" than FF for daily usage should remind people that resting on your laurels is not an option. What cut the mustard 5 years ago isn't gonna cut it any more.
Reality check (Score:4, Insightful)
5 years ago people people would constantly belittle IE users because it had frequent crashes, and pointed to the 'superior' Mozilla suite. 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.
No I don't have a source for my statement. But ask people you know who are not in the tech industry. The one outlier group is Mac users, who don't realize that closing a browser window doesn't take the program out of memory.
Re:You're already tolerating it by using it at all (Score:4, Informative)
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]
A possible fix? (Score:1)
the solution is simple (Score:1, Interesting)
An act of balance (Score:5, Insightful)
(http://www.stopcomputerlicens.dk/ | Last Journal: Wednesday August 01, @08:24AM)
Some would argue that the problem is sloppy coding, or poor encapsulation (a typical OO programmers point of view). But please remember, that even though modern browsers are GUI apps, they are coded much like low-level server processes or protocol stacks. Low-level programming using languages like C and C++ gives you more control and better performance, but at the expense of nicer development features like garbage collection and encapsulation.
Think about it. Would you accept a browser that rendered HTML flawlessly and with absolutely no memory leaks, but took more than a minute to render each page? I think not.
It's an act of balance, and the problem is not _always_ "sloppy coding". It is the increasing complexity of these apps, combined with user demands which push the development towards low-level development languages. From a realistic point of view, any app. written in low-level C with as many lines of codes as FF, is bound to have bugs and leaks. (perhaps except code controlling nuclear reactors and NASA satellites, but then the price of each line of code is also somewhat different).
We - the end users - are not without blame.
- Jesper
Time-based cache (Score:2)
(http://slashdot.org/~Spy+der+Mann/journal/ | Last Journal: Wednesday November 07, @12:32PM)
Why tolerate? (Score:1)
Because other browsers have their problems too, and I have to web browse with something.
Might as Well Fix Javascript Too (Score:2)
(http://www.5sigma.com/joseph)
Time To Chill (Score:1)
"Do you want some cheese with that wine?" - Unknown
Where are the leaks? (Score:2)
Cautiously avoiding the mention of anyones favorite O/S so as not to earn troll mod points; It all depends on where the leaks are. The only way to fix some of them would be to build a staticly linked executable. That still doesn't get you around kernel/driver bugs. In my experience, many apps that appear to leak quite badly on one system do very well on another.
Hint: Try setting "LEAKS=OFF" in the registry. ;-)
More prevelant on Mac? (Score:3, Interesting)
Running "bare bones" on all Firefox installs, no plugins other than whatever may have been included with the base distribution.
Does anyone else notice this? I've switched back to Safari on the Mac in the meantime.
Ah, The Joy of C/C++ (Score:1)
(http://freejavalectures.googlepages.com/)
What leaks???!?? (Score:2)
(http://www.liquidshells.net/)
49GB! (Score:2)
(http://moore.cx/dan)
Firefox memory leaks - (X11 specific) (Score:5, Informative)
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
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.
About time (Score:2)
Memory Leaks is the most trivial of issues. (Score:3, Insightful)
IE has been lowering the CPU priority of Flash applets for years so if you have 100 Flash ads open, it won't bog down your browsing. On Firefox, try opening a couple of tabs in Yahoo and it basically grinds to a halt.
It used to be that in NS4, I could see "nsplugin" process so I can renice that to achieve the same effect. On Firefox, it's not possible.
And, if you happen to leave Gmail open, my CPU usage (lowly Sempron) will hike to 30% twice a minute. On IE the CPU usage stays low. I suspect it's due to a multi-threaded Javascript engine in which individual thread can be prioritized.
Permenant usage for digital sign required IE7 (Score:1)
After the memory fixes.. (Score:1)
Leaks void my warranty (Score:2)
this aint the problem (Score:1)
(Last Journal: Sunday October 28, @11:25AM)
worrying about a little performance is a classic geek mistake; people buy features, not performance.
what are features ?
I have poor vision, and Cntrl+ doesnt increase the size of the text in the url window
the poor state of organization of the site where you down load extensions
I'm sure all the non geeky
Or how about better export and save of urls
or
or
remember, people buy features, not performance - if that werent true, how would MS rule the world ?
Could Linux be the difference? (Score:2, Interesting)
(http://opensourcetoday.org/)
I used to be a casual tester for both versions 1.5 and 2.0 and I switched to each well prior to their offical release. What I noticed was much more effort was expended creating satisfactory working versions on Windows over either the Mac or Linux. Nonetheless, I have been pleased with the results. My use of the coming version 3.0 has been very limited running of most of the stable alpha versions. So far my limited exposure seems to see an improvement over 2.0. Another factor that could make my experience worse, is that I use the Mozilla version that I install by hand. I have long ago not bothered to even update the supplied distribution version. Nonetheless, I have no complaints.
Another factor that should degrade my experience, is my machine's inners are not of that recent vitage having only one Gig of RAM and a much older AMD CPU. Might some of the problems so vociferously expressed here be due to other factors than so loudly proclaimed?
I am well aware that supposedly identical machines, with the same software can behave very differently. Had that experience with corporate property using NT and XP, where I could get to Unix and the version control system while a neighbor could not. Nonetheless, I find it odd that my experience is so at odds with the many that have written.
I've given up on Mozilla. (Score:2)
First it was the MNG/JNG farce - you have to see this for yourself [mozilla.org] to believe it. 5 years (!!) of making up bullshit excuses later they dump an inferior, crippled "replacement" format in the browser to force everyone to give up.
I won't comment on their side project to make a faster, smaller, less bloated browser... you can all see what a success that's been.
Now for some reason despite all the times the mozilla people have done this -- much more than the two examples I've mentioned -- I was still using Firefox last month. Then it broke spectacularly on me (which was to be expected given it was a CVS build), so I load 2.0 up again and I realise half the extensions I have installed in it are to fix bugs and security holes it shouldn't have in the first place. I can name Noscript and Long Titles off the top of my head. I realised there was no reason to keep using this crap just like there was no reason to keep using windows.
Memory leaks aren't Firefox's biggest problem -- it's the inmates running the asylum that is. Until that's fixed, I'll be using Konqueror. (if you want to know why I won't use opera, substitute developers for users)
24 Hours (Score:2)
First Post! (Score:1)
(http://is.gd/)
Actually at least with the Windows version, I haven't noticed much of a problem with memory leaks personally. I guess that's probably because I finish whatever I'm doing and tend to close all my FF windows at least once every few hours though. Anything to fix bugs and lower resource usage is always a step in the right direction though, so I'd have to applaud this action regardless.
Concurrency and Responsiveness (Score:3, Interesting)
(http://www.ferrus.net/)
Although Firefox does have some issues with memory usage (and occasionally memory leaks), that doesn't seem the be the primary cause of usability issues.
In my personal experience with Firefox, I see two problems:
Both of these problems could be solved relatively easily with threads (in a number of different ways), but for some reason the Firefox developers have an irrational paranoia of anything that even vaguely resembles native concurrency. They say "the real problem is just response time, if we can respond fast enough in a single thread it's the same" - but then they never actually do it, and they definitely don't do anything that would let them recover from component crashes.
is downgrading a solution? (Score:1)
Hoorah! (Score:2)
(http://slashdot.org/ | Last Journal: Monday January 31 2005, @05:48PM)
I'd like to nominate this whole thread for... (Score:2)
90%+ of the c/c++ guys have no clue.
99%+ of those bagging on GC have less of a clue.
They might as well be talking about girls...
Geez.
Why slow to fix? Fixing memory leaks is easy (Score:2)
One frustrating thing about this is that fixing memory leaks is relatively easy. To have any memory leak is unnecessary and a sign of a mediocre programmer.
To find a memory leak just instrument the memory allocator. See what's left when you exit the program and that's your memory leak.
There are several commercial/freeware packages that will do this or just roll your own. This will catch all memory leaks that aren't caused by memory corruption, including ones created by threads, addons and interpreted code. You can even use it with a garbage collector to see why certain blocks of memory aren't being freed by the collector. It has an overhead but not a major one and on a fast development machine it's easily usable, particularly if you're able to take advantage of a second CPU.
The firefox developers should create a beta build with instrumented memory allocation. Better yet make it part of the standard build (it's small) and enable it with a configuration option. The instrumentation could be made quite sophisticated with arena's, snapshots, tagged allocations and the like but even a basic calling PC log would be a big win.
Memory corruption is a different ballgame. For that you need to do much more sophisticated instrumentation that will catch bounds violations and unallocated pointer access. Possible, but can cause the program to run so much slower that it becomes impractical to do on a large scale. Should still be done occasionally though just to see what obvious, easily fixed violations are occurring.
---
Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.
Well, at least there's a new marketing angle... (Score:1)
There is no major memory leak (Score:2)
(http://www.enderandrew.com/ | Last Journal: Tuesday July 03, @11:44PM)
1 - The code already has been tested with garbage collectors, Valgrind and the like. Most memory leaks hopefully have already been caught, but they are recommitting themselves to this task.
2 - Mozilla is not responsible for the poor javascript and such prevalent in various extensions written by third parties.
3 - This is the most important part, the massive memory and CPU usage is a feature, not a bug, and can quickly be disabled. Firefox 2 and 3 cache fully rendered versions of pages, so that it is "quicker" when you hit the back button. It doesn't have to rerender the page. Personally, I don't care for this feature, and so I tell Firefox to use less memory.
http://kb.mozillazine.org/Memory_Leak [mozillazine.org]
Google is a powerful tool. Slashdot readers should familiarize themselves with it before crucifying Mozilla.
Performance, performance, performance, performance (Score:2)
(Last Journal: Thursday December 02 2004, @08:18PM)
In all seriousness though, I want performance from FF, feature wise the latest stable 2.0 releases with the addons I've installed (about 6 iirc) is more than enough for my _current_ needs.
I want to see this application pick up in speed, a lot.
Sure it's fast now but goddamnit people I (you?) want more - I've got 4gb of ram, I've got dual core processors, I've got fast hard disks but still the web isn't fast enough.
I'm not a developer, I'm an enthusiast, take my posts with as much salt as you like but I've found the speed of opening web pages hasn't particularly improved that much in the past 10 years.
Sure the pages are more complex, no denying it, I'm not completely dopey.
We used to open what? 50kb of html / images on dialup 10 years back, now how big is your average page, (I honestly don't know) but based on my bandwidth use, quantity of pages I hit, I think it would surely have to be under 500kb.
See the thing is, I don't find the cache use in any browser clever enough, it just doesn't seem to get hit enough at least that's what I'd theorise.
While I'm at it, the one thing I've found which increased performance massively for me was a small application called 'easy dns' - I believe it's no longer available and either way I can't install it on every machine I browse on, but it was a DNS caching tool, lets you add up to 10 DNS servers, it would chose the best ones AND cache whatever ones it had already opened.
When your browser hits
This may come across like a big whine but honestly, I think FF is fantastic, the features are rich and it works well but hell, let's keep improving, I'd love to see the web truely, amazingly quick.
While I'm on that note, perhaps some performance tips for FF would be in order, anyone got any?
How about fixing the broken contextual menu in OSX (Score:1)
(http://www.gis.net/~cht)
In 2.0 and up, you HAVE to hold down a key on the keyboard and right click.
And there is NO preferences option to change it back.
What dipwad thought THAT was a good idea?
Fix the broken usabilty/human interface bits, as well as the memory leaks and then maybe you'll have a decent browser once again.
In the meantime, I'm sticking with 1.5. The FireFox browser that's not broken.
it was about time (Score:1)
What the hell are you people doing? (Score:2)
(http://rapture-cms.com/ | Last Journal: Tuesday June 24 2003, @02:11PM)
I have a gig of RAM, 256 of which goes right to a VMware instance, run Outlook all day long, usually have photoshop open, and work with Firefox all day long. Multiple tabs, plenty of fun little extensions, Flash, the whole package.
So what clues you into Firefox's memory usage? Does your system start running slowly? Or are you opening Task Manager seeing Firefox is using 200megs and getting angry?
Maybe I have better luck because I shutdown nightly.
Memory leaks are a sign of bad management (Score:1)
(http://slashdot.org/)
So when a company or group of coders say they can't fix their memory bugs, I say bull----. When they say that the parent company doesn't pay for fixed code, that I believe.
So if ten years after a small team of four had a bug and memory-leak free code stack, the fact a browser still leaks like a stuck pig after the hundreds of thousands of hours of code that went into Firefox, then it's obvious where the fault lies.
Especially because if they prioritized that fix, coders like me might actually be interested in contributing again.
Re:And on three... (Score:5, Funny)
Re:And on three... (Score:2)
This is long overdue and is the cause of my biggest gripe with Firefox. Without a couple vital extensions related to my work, I would have ditched FF for IE7 because of this issue. I absolutely hate having to Force quit the
Re:Here we go... (Score:5, Insightful)
There is no reason why a minimal web browser could not be implemented, utilizing something like ~100kb of memory, in fact, i have seen the code to one. However, it wont be a) fast b) portable c) full featured d) very easy to understand
Re:And on three... (Score:5, Interesting)
Every time someone mentions memory issues, the responses are either that it's supposed to consume a gigabyte of ram so that it speeds up the back button or that "there is no memory issue".
Strange, now, that there are suddenly people paying attention to specifically attacking memory use issues that supposedly don't exist.
Re:I thought this was OSS? (Score:3, Informative)
(http://www.stopcomputerlicens.dk/ | Last Journal: Wednesday August 01, @08:24AM)
Observing the existence of a memory leak, and knowing where to fix it in your code, are two VERY different things.
- Jesper
Re:Here we go... (Score:2)
Re:Here we go... (Score:2)
Re:Why I tolerate it (Score:2)
The story is about how many leaks have been found and fixed. How do you see that as a bad thing? Or do you mean that with open source development model, these bugs shouldn't been there in the first place? Well, Firefox is based on Mozilla Application Suite, which is based on Netscape Communicator, which was developed as closed source application, before it's source was released in 1998.
http://en.wikipedia.org/wiki/Mozilla_Application_Suite [wikipedia.org]
Re:Why I tolerate it (Score:2)
Re:Try Opera (Score:1)
Now this was probably a year a go I tried it... So there is a fairly good chance I might be talking out of my ass now.
Re:Here we go... (Score:2)
(http://www.edgeio.com/ | Last Journal: Wednesday March 09 2005, @10:42AM)
That memory usage is mostly leaks. Whenever I get Firefox to 1.5-2GB, and close down all tabs, so my only page open is about:blank, and I clear out my cache, and tune the Firefox settings to minimize caching etc., most of that memory never gets freed up.
Now, it's certainly true that there's a lot that could be improved to reduce memory usage further, but I'd be perfectly happy just to get rid of the leaks. It's not like I regularly "need" to have 80+ tabs open, and even if I do, my machine is perfectly usable with 80+ tabs open initially after a restart if/when that is what I want to do, and I'll still have plenty of memory free.
Re:Here we go... (Score:2)
(http://www.the-h.net/h)