Archive for the 'Mozilla' Category

A dangerous ambiguity

Wednesday, November 7th, 2007

Brian Krebs recently posted a blog entry, Hiding In Plain Sight, about the continuing problem of executable files disguised as other types of files. Brian explains how to make file extensions visible on Windows XP and wonders why Microsoft didn't make that the default.

But hiding the extension by default is only part of the problem. Most users can't be expected to memorize the meanings of dozens of three-letter filename extensions. Even advanced users can't be expected to check the extension every time they download a 15-second video clip.

The real problem is that the same action -- double-clicking on a downloaded file -- has a completely different meaning depending on whether the file is a document or a program. In the first case, it means "view this document"; in the second case, it means "grant this program all of my privileges".

Mac OS X 10.5 "Leopard" tries an interesting solution: "quarantining" just-downloaded programs. If you download a program using Safari or Firefox, you get a concise dialog reminding you that it was downloaded from the Internet.

Unfortunately, Apple botched an important part of this dialog: the button label. The OS X HIG suggest that button names should be verbs that describe the action performed, so if users only read one word in the dialog, it will be one that differentiates one action from another. (Windows, in contrast, is notorious for using "Yes" and "No" as button labels.) Apple chose the verb "Open", which suffers from exactly the same problem as double-clicking: it has a vastly different meaning for documents and applications!

There is concern that because the dialog is "in the way of what you were doing", many users will click through no matter what the dialog says. So perhaps a better solution is to take a hint from the Web application security model, and grant fewer privileges to most local applications. Why should running a screen saver or local game be so much more dangerous than visiting a web page?

A third possible solution is to make the action to launch an application explicit. In a command-line setting, this action might be "chmod +x". On Mac, a natural choice would be dragging the application to the Applications folder, since that is already a normal part of installing an application.

For now, my workaround is to drag files to VLC (as a habit) instead of double-clicking them. I suggested this in the "Handling downloaded files" section of Security tips for Firefox users.

Mac OS X Ultimate

Thursday, November 1st, 2007

At WWDC in June, Steve Jobs made fun of Vista's pricing and said that there would only be one version of Leopard, at $129. But now we're finding out that only Mac OS X Server may be run virtualized. Since there are plenty of reasons to use virtualization other than for running servers, does this mean that Mac OS X Server is slowly turning into Mac OS X Ultimate?

Slashdot party tonight

Thursday, October 25th, 2007

Slashdot was largely responsible for my initial involvement in the Mozilla project, so I'm looking forward to the Slashdot anniversary party in Palo Alto tonight. Are any other Mozilla people going?

Meeting spot

Monday, October 8th, 2007

Google suggests holding tomorrow's leak meeting on a cruise ship.

Somehow I don't think that would work very well. Leaks and ships don't get along perfectly.

Fast turnaround for leak bugs

Saturday, September 22nd, 2007

I turned on trace-refcnt a few days ago in order to find leak bugs. I found three yesterday and three today.

Four of the six bugs already have patches :)

Firefox memory usage and memory leak news

Thursday, September 20th, 2007

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.

Memory usage

Federico Mena-Quintero submitted a patch to make Firefox discard decompressed image data after five seconds (bug 296818). ImageLib module owner Stuart Parmenter experimented with a competing idea in bug 386377, but now he plans to help with Federico's patch. The patch will make image data join text runs in using time-based caching rather than traditional space-bounded caching.

Aaron suggested having an "about:memory" page showing a breakdown of Firefox's memory use (bug 392351). When I pointed out the bug to Brendan Eich, he excitedly assigned the bug to himself.

Eli Friedman discovered that nsFloatCache was no longer necessary and eliminated most of it (bug 381385).

Memory leaks

David Baron checked in a patch for the last bug that contributed to RLk on Linux, bringing the number of XPCOM objects leaked during this test to zero. Since this test runs on Tinderbox, it's likely that regressions will be noticed quickly, even if they don't turn Tinderbox orange.

Robert Sayre created a script to load random pages and see whether they cause leaks. The random URLs come from the Yahoo directory (biased toward older, top-level pages), del.icio.us (biased toward newer, geeky pages), and AltaVista (biased toward pornography). The script detects leaks using trace-refcnt, the same test used by RL; future versions might use trace-malloc in order to catch additional leaks. Robert has caught at least 6 distinct leak bugs using this script, 3 of which have already been fixed. See LeakingPages and bug 394517 for details.

David Baron created a series of patches to the cycle collector to aid in debugging leaks. With this code, DEBUG_CC builds of Firefox can notice when an object "expected to be garbage" is not collected and then explain in detail why it was not collected.

Steve England tested the top 500 web sites, finding two leaks. Later, he tested the top 20 Firefox extensions and found leaks in several of them.

David Baron recorded seven leak debugging screencasts, which you can watch to see how David Baron debugs real leaks.

Kris Zyp found a leak in the JavaScript Engine when using the watch method (bug 394709). Igor Bukanov responded quickly with not only a patch for the bug but also a leak detection patch to enable regression testing of JavaScript Engine leaks. I asked him to modify his patch so I could use jsfunfuzz to test for JavaScript Engine leaks, and he did. (This led me to find several bugs in evalcx, but no additional leaks.)

David Baron got the stack walking code and the stack fixer working on Mac, making it possible to use trace-malloc and the refcount balancer on Mac (bug 336517, bug 392118).

How to help

You don't have to be a C++ programmer to help find leaks in Firefox.

If you're a Firefox user, an easy way to help is to browse with a trunk nightly build wrapped in a script that calls leak-gauge.pl when Firefox exits. If it reports that documents or windows leaked, try to figure out how to reproduce the leak and then file a bug report.

If you're an advanced user, you can do something similar with with trace-refcnt, which detects leaks of all reference-counted objects, not just windows and documents. Build Firefox with the .mozconfig option "--enable-logrefcnt" (or build debug) and run your build with XPCOM_MEM_LEAK_LOG=2. When Firefox exits, it will print a detailed but understandable summary of what types of objects leaked.

If you're are a C++ programmer and want to help diagnose or fix bugs, check out Performance:Leak_Tools along with David Baron's screencasts, and hang out in #developers on irc.mozilla.org.

Valgrind coming to Mac

Wednesday, September 19th, 2007

Apple employee Greg Parker has ported Valgrind to Mac, and plans to release his work soon after Leopard is released in October. He's been working on it for quite a while.

I'm excited about being able to use Valgrind on Mac. Valgrind's "Memcheck" is much better at catching dangling-pointer bugs and heap buffer-overflow bugs than simply watching for crashes (even with MallocScribble enabled). Running a fuzzer with Memcheck can reveal exploitable memory safety bugs that would not have triggered crashes otherwise.

Update 2008-09-29: Greg Parker has released his port as a patch.

Update 2009-02-06: Valgrind developer Nicholas Nethercote has imported Greg's patch into a branch of Valgrind's SVN repository.

Update 2009-06-02: Valgrind trunk now supports Mac.

Introducing Lithium, a testcase reduction tool

Saturday, September 15th, 2007

I wrote a tool called Lithium that automatically reduces large testcases, such as real-world web pages or testcases produced by jsfunfuzz. It can usually reduce a 3000-line jsfunfuzz crash testcase to 3-10 lines in several minutes, considerably faster than I can reduce by hand. Perhaps more importantly, I can do something else while it reduces the testcase.

There are two (related) reasons I'm not calling it "Lithium 1.0" yet. First, I'm hoping to improve the way "interestingness tests" are written. Currently, they're separate programs that communicate to Lithium using their exit code, which limits error handling and might slow Lithium down. I'd like to make the interestingness tests be Python files, but I'm not sure what the best way to do that is. (Should Lithium __import__ the interestingness test? Or should the interestingness test import Lithium and be renamed to e.g. "reduce_crash.py"?)

Second, it would be useful to be able to pass extra arguments to the program being tested. For example, it would be useful to be able to pass a profile name to Firefox, or to pass a Firefox path to Valgrind. One possibility is to put the program being tested last on the command line, so extra positional arguments become options to that program. This solution would only work for interestingness tests that launch a single program (so it wouldn't work for a "renders differently in these two Firefox builds" test, for example), but maybe that's okay. Another possibility is to require the use of a config file for passing arguments to programs being tested (so you don't end up typing all of ".../firefox-bin -P foo" on Lithium's command line).

I'll probably use the MIT license for Lithium (but not for timed_run.py, which was mostly written by Chris Cooper and Bob Clary).