611 Defects, 71 Vulnerabilities Found In Firefox

Danny Begonia writes, "Some folks at Klocwork examined the large and complicated code base of the popular open source browser, Firefox. Overall, Firefox is a well written and high quality piece of software. Several builds were performed on the code, culminating in the final analysis of version 1.5.0.6. The analysis resulted in 611 defects and 71 potential security vulnerabilities. The Firefox team has been given the analysis results, and they will determine if or how they will deal with the issues." What are your thoughts — do Firefox and the open source community welcome this kind of analysis?

Memory leaks

[Anonymous Coward]

It seems mainly the problems were to do with memory leaks. Which having seen firefox eat 700mb of ram doesnt surprise me....As long as these probs get fixed i cant complain...Doning this kinda of analysis is much easier with the source code i imagine.

I value it

[jimstapleton]

as a user, I value this kind of criticism - it's better out in the open where the devs are pressured to do something about it, than behind close doors where those of malicious intent can go about their nefarious business unhindered.

Better than the alternative

[TheWoozle]

Closed-source software companies are paranoid about this sort of thing. They are often openly hostile, to the point of suing anybody who does this sort of analysis.

One would certainly hope so...

[tcopeland]

...I recently wrote an article for Better Software (details here [blogs.com]) showing the duplicated code and some other static analysis-type problems that PMD [sf.net] turned up in two fairly popular open source Java apps - Azureus and Columba. Both these programs are excellent open source apps, but both also had a number of places that could be improved.

This is kind of a Slashdot permathread, but anyhow, static code analysis is not a replacement for smart people also looking at the code. Rather, it augments folks' efforts and provides a safety net to catch little problems that can slip through. A duplicated code detector [sf.net] is especially useful because it can scan a massive codebase and help pick out chunks of code that can be refactored away. This reduces the lines of code, eliminates the possibility of duplicate bugs, and is great fun.

Re:Obvious.

[legoburner]

Especially now that firefox is so popular. Firefox makes up 10% of users on the general Internet (as counter by thecounter.com [thecounter.com]), with IE at 85%. My own tech related site [comparecomponents.com] has 76.4% of users using firefox, with just 10.1% on IE, and my other more casual site has 23.1% firefox and 64% IE (the rest being safari, opera, konq, etc.)

Re:Memory leaks

[random_culchie]

This and the God-damned copy and pasta bug!!! Firefox devs fix this one long term bug and I will sacrafice some cattle. I swear. Its driving me nuts..

College Lab

[ThreeDeadTrolls]

I did a lab last semester where two computers where set up, one running IE, one Running Firefox. I attempted to hack both of them using the BackTrack distro... a linux distrobution with a ton of tools and hacks to test vunerubilities. The conclusion? It took me less than 5min to hack the Box using IE through the browser. Took me 4 days for Firefox.

Re:Why Not?

[arth1]

Why wouldn't they? Ego, unfortunately. Open source developers are just as human as commercial developers, and don't like anyone badmouthing their babies.
Yes, I expect a fair number of these bugs to be fixed, but I also expect a fair number of them to be closed without action, if there's any way to pass the blame.
"Package A leaks memory when used with package B? Package B needs to free the memory we allocate. Not our fault. *CLOSED*"
"Package A has a buffer overflow vulnerability? Packages B and C must filter the strings they send us. Not our fault. *CLOSED*"
"Package A has a buffer overflow vulnerability when used with Unicode? It's designed as a single-byte character routine. If you want a multi-byte one, write your own. Not our fault. *WONTFIX*"

I hope and trust that most of the bugs will be fixed without politicking and passing the buck, but I fear there will be quite a bit of focusing on blame placement and credit taking instead of getting a thankless job done.

Regards,
--
*Art

Disable-Output-Escaping

[jkeegan]

Well they certainly don't appreciate being reminded that they still don't support the disable-output-escaping feature of XSLT..
http://bugzilla.mozilla.org/show_bug.cgi?id=98168 [mozilla.org]

What about library dependancies?

[DigitAl56K]

It's great that the Firefox codebase has been scanned, but surely Firefox also depends on other open-source libraries? If these are not also scanned then the analysis is incomplete (although still much better than nothing).

Re:Memory leaks

[Dan Farina]

Except this isn't a memory leak, but is in fact intended behavior. A memory leak is a fairly specific and (and in this case) a non-applicable bit of terminology, unless there is more to that article and comments linked to that I'm not seeing. You could instead argue that the behavior is not a good one unless you point to a reference that shows that this memory usage is, in fact, caused by a leak.

On one side of the fence are those who say ram is cheap and we shouldn't care, but when "big" becomes "too big" is a point that is of some subjective judgment. I for one never have swapping problems with my workload and have firefox open for days, so I'm not inclined to care.

Re:Why Not?

[Jerf]

If the GP is correct, it's still bad usage of the bug system. If Team A feels the fault belongs to Team B, the correct response is to move the bug to Team B, not to close the bug.

They may get into a fight about whose responsibility it is, but such a fight is also a bug, as such responsibilities in such a large project basically are a part of the code and should also be clearly delimited. If you insist on using languages without automatic garbage management, "who's responisibility it is to deallocate this memory" is a fundamental part of the API.

Re:Speaking of which... (Was Re:Obvious.)

[rucs_hack]

slightly OT I know, but relevent:

Back when I was a nurse, in the days before programming sucked me in, I was a manager in a private elderly care home for people with dimentia.

We kept excruciatingly detailed records of every scratch, cut and injury, serious or otherwise, that happened to our clients. So much so that on paper our accident record look awful compared to other homes, who tended not to be so open. We actually had fewer such incidents then other homes in our region, but we documented *everything*.

However, come official inspection day, the health authority inspectors were always very pleased with our records, and always passed us with a very high grade.

The reason? Instead of hunting around for hidden evidence that had been concealed, they just had to consult our records.
We were open about problems, and always sought solutions. We were also, because of our policy on recording everything, able more easily to identify problems with patients who were more likely to get cut, and work to alter their environment or diet to try and help.

The result was that we ended up being the top specialist care home in our region.

When I moved into computer science, the only software model that I would work with was open source. Again there is nothing gained from hiding problems with code, and it's much easier to identify issues. I discovered remarkable similarities with my old nursing practices and the Open Source method.

I realise the comparison may seem odd, but my point is that being open about problems is a far better way to reach solutions, whatever field it is applied to.

Do they welcome this?

[pherthyl]

Of course they welcome this. Just look at the results page for the Coverty scans and see how many defects have been fixed in major open source projects.
http://scan.coverity.com/ [coverity.com]

The Firefox team needs the help.

[Futurepower(R)]

Firefox is the most unstable program in common use [slashdot.org]. Some of the most serious bugs, like the CPU hogging bug, are more than 4 years old. So it's great that the Firefox team is getting some help. They need it.

(Note that the main bug report linked is always marked invalid. That's not because anything has been done about the instability of Firefox; it's because people on the Firefox team don't want to, or don't know how to, fix the very, very serious bugs. Note also the links to magazine articles about Firefox instability, and the many links to user reports of problems.)

I'm posting this comment from Firefox version 1.5.0.6. It is using 22 percent of the CPU, even though all pages have been loaded, and there is no active content. That's 22% on the way to 70% or more, which will soon make it necessary to close all windows and tabs of Firefox and reboot Windows XP. (Firefox corrupts Windows XP SP2 with all patches applied, so that it is necessary to restart the OS. In Linux, it is necessary only to kill Firefox to get full control again.)

The CPU hogging bug in Firefox runs the fan in a laptop computer continuously, meaning that expensive hardware maintenance will be required more often for heavy Firefox users.

Firefox has extensions, but they often make Firefox unstable. The Firefox team thinks that it is entirely acceptable to market Firefox extensions, but when the extensions cause Firefox to be unstable, to excuse the instability by saying that it is caused by an extension.

The 1.5.0.4 version of Firefox was quite stable, if the Flashblock extension was installed. The 1.5.0.6 version is unstable again.

The problem appears to be that Firefox does not allocate enough resources. If you open several Firefox windows and several tabs in each window, and leave them open for several days, or suspend or hibernate your computer a few times, you will find that Firefox has started to hog the CPU.

It is interesting to note that, when the latest version of Firefox is used with the latest version of Thunderbird, they both have trouble with the CPU hogging bug. The each corrupt the other. Weird, and seemingly a good clue to the flaw that causes CPU hogging.

Apparently everyone on the Firefox team wants to add features or work on easy bugs. Apparently also, browser programmers are not necessarily heavy browser users. People who often do research on the internet, and open several Firefox windows and many tabs, and leave them open for several days, are certain or almost certain to cause Firefox to become unstable, however.

Mozilla Foundation Top 14 Excuses for Not Fixing Bugs

Top 14 things Firefox and Mozilla developers say about those who report difficult bugs, collected during the last 4 years:

1. Maybe this bug is fixed in the nightly build.
2. Yes, this bug exists, but other things are more important.
3. 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.]
4. If you would just give us more information, we would fix this bug.
5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
6. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
7. I don't like the way you worded your bug report. [So, I didn't read it or think about it.]
8. 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.]
9. Many bugs that are filed aren't important to 99.99% of the users.
10. If you are saying bad things about Mozilla and Firefox, you must be trolling. [They say this even though Firefox and Mozilla instabili