{"id":660,"date":"2009-03-19T23:18:33","date_gmt":"2009-03-19T23:18:33","guid":{"rendered":"http:\/\/neosmart.net\/blog\/?p=660"},"modified":"2013-08-26T18:18:43","modified_gmt":"2013-08-26T23:18:43","slug":"on-the-matter-of-firefox-and-memory-leaks","status":"publish","type":"post","link":"https:\/\/neosmart.net\/blog\/on-the-matter-of-firefox-and-memory-leaks\/","title":{"rendered":"On the matter of Firefox and memory leaks…"},"content":{"rendered":"

Recently our original article\/rant on Firefox’s legendary memory abuse<\/a> has seen an increase in comments and views; and I had intended to post the following comment in light of the article’s rebirth and the ensuing discussions in the comments.<\/p>\n

The reply turned out to be longer than I’d originally intended, so here it is as its own post.<\/p>\n

\n

I’ll try to be as objective as possible in this reply:<\/p>\n

The most important thing for frustrated end users to keep in mind is that Mozilla\/Firefox cannot be held responsible for cases where incorrectly written plugins and\/or extensions cause Firefox to abuse system memory – that’s the trade-off between empowering developers and keeping the code squeaky clean.<\/p>\n

Most of the cases reported are indeed caused by one or more extensions or plugins gone awry, doing something they shouldn’t be doing, or something they don’t know how to do properly. Some of the most popular plugins for Firefox are notorious for their memory leaks; but few users realize just how dangerous they can be, and that the Firefox devs cannot really do anything about it.<\/p>\n

At the same time, there can be no doubt that Firefox has some memory leaks in the codebase itself. They’re clearly not easily reproducible and they don’t happen very readily nor often enough because the developers have clearly spared no effort in their attempts to address this problem for once and for all. But they’re there, nevertheless.<\/p>\n

<\/p>\n

No matter how you look at it, the fact remains that under certain circumstances, doing certain stuff on certain machines in certain ways for certain people, Firefox still leaks memory. A lot. On Mac, Windows, and Linux. Yes, on clean installs too.<\/p>\n

Now as a systems developer (Mac, Windows, and Linux w\/ their respective native APIs; embedded systems; .NET and more with years of experience), I must say that of all the bugs and problems I’ve ever encountered, there is nothing that “cannot be fixed.” To say that this behavior is out of Firefox’s hands because it’s not their code that’s causing the problem is simply not true.<\/p>\n

I’ve experienced memory leaks like this (and worse) in my own code in the past, largely due to stupid mistakes and silly oversights. It takes extreme<\/em> persistency to make memory leaks go away – a willingness to spend 24 hours on-end & non-stop crawling through code, memory dumps, and stack traces to try and find out where things are going wrong. It requires remote debugging on allegedly-affected machines. It requires reading through dozens to hundreds of sometimes clueless users describing in the most general of terms what they were doing when things went wrong. In short, it requires a lot of effort and very little recognition and a hell of a lot of hair-pulling.<\/p>\n

But it can be done.<\/p>\n

C++ is an incredibly powerful language. If you know the code you’re developing and the systems you’re writing it for, there’s nothing you cannot fix. Dynamic memory allocation is the biggest gift\/curse in the world, but in C and C++ if you can allocate something that means you can free it. Even if you don’t have a mechanism to find out where it is and how it got there. But you just have to be cunning enough to figure out how to track them down and set them free, taking care to know when and where to do so safely…. and you have to be familiar with every single routine and how they work; which is obviously extremely difficult with codebases as large and complicated as Firefox’s.<\/p>\n

There are even workarounds for the memory leaks (assuming they can be isolated) if the developers aren’t willing or capable of doing the aforementioned. If you’re dealing with leaky libraries that you can’t fix, in the very worst-case scenarios you can hook into them at runtime, access the functions you need, reserve the memory required, get the job done, copy only<\/em> what you need,\u00a0then free it right back. All of it. You can have helper threads or processes handle this stuff then wipe them and their memory spaces clean when they’re done to complete the memory insulation.<\/p>\n

There’s a lot of stuff that can be done, and none of them are easy. But the journey of a thousand miles begins with a single step, and developers and evangelists denying a problem exists isn’t the way to go about addressing the matter at hand.<\/p>\n<\/blockquote>\n

At the end of the day, Firefox is a great browser and any complaints about its performance and its shortcomings are only out of a sense that it can do better – that it has to in order to remain at the top of its game in a cutthroat market of only the most intense of competition.<\/p>\n","protected":false},"excerpt":{"rendered":"

Recently our original article\/rant on Firefox’s legendary memory abuse has seen an increase in comments and views; and I had intended to post the following comment in light of the article’s rebirth and the ensuing discussions in the comments. The … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":505,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[212,60,77,696,206,11,901],"class_list":["post-660","post","type-post","status-publish","format-standard","hentry","category-software","tag-development","tag-firefox","tag-memory","tag-memory-leaks","tag-mozilla","tag-programming","tag-software"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4xDa-aE","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/660","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/users\/505"}],"replies":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/comments?post=660"}],"version-history":[{"count":1,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/660\/revisions"}],"predecessor-version":[{"id":2553,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/660\/revisions\/2553"}],"wp:attachment":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/media?parent=660"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/categories?post=660"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/tags?post=660"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}