Indistinguishable from Jesse

Finally, a bug-tracking system for everything. The priorities, severities, products, and components are great.

The Firefox Tinderbox has been unmanageably wide lately. I wrote a Greasemonkey script, TidyBox, to fix it by moving build results from the table cells to popups that appear when hovering the table cells.

Looking at a screenshot with TidyBox, it's easy to see that exactly one box is orange and that the orange started after the last checkin. With the normal Tinderbox display at the same time, you would probably have to scroll both horizontally and vertically to figure that out.

If you want to see the information about a build while using TidyBox, just hover over the cell. To click links that appear in the popup, click the cell to lock the popup in place and then click the link.

Install TidyBox today and you might never have to scroll Tinderbox again!

Other recent efforts to improve Tinderbox:

• Johnath: Performance Dashboard
• Mossop: Tindermerge
• Vlad: Talos Fix

Mike Shaver and Johnny Stenback are doing their part. Are you?

Crashtest is Mozilla's newest test suite. It provides a very simple way to make sure a page doesn't cause Gecko to crash (or hang or assert or leak). Since I report a lot of crash and assertion and leak bugs, I've been looking forward to being able to use this test suite. (For some bugs, I had been using "== about:blank" and "!= about:blank" reftests, but most of my bugs weren't getting tests checked in at all.)

I spent most of last week making crashtests for old bugs I had reported and checking them in.

So far, these crashtests have found bug 409150, a crash on Windows that happens on Tinderbox but not dveditz's computer, and bug 408746, a crash on Linux that happens on sayrer's computer but not on Tinderbox. They also found a problem in a patch before it was checked in.

The value of crashtests (and reftests) goes beyond keeping regressions out of nightlies. The test suites can be run under Valgrind's Memcheck, potentially finding subtle memory safety bugs that don't normally show up as crashes. The pages can even be used outside of the normal test framework, for example for finding inconsistent-rendering bugs.

Lately, I've been running debug builds of Firefox with trace-refcnt summaries enabled and reporting any leaks I can reproduce. Frequently, someone else quickly attaches a patch, but in the case of bug 401393, nobody else could reproduce the leak I was seeing. For me, simply loading a page with Flash and scrolling down could leak several objects.

Boris helped me use more detailed trace-refcnt logging options to figure out what caused the leak, and then Jonas assigned the bug to me:

Jesse, here's your first blocker :)

Let me know if you need help and I'll do my best.

I was able to fix the leak, although I still don't understand much of the code for the class I modified. Boris and I also figured out why not everyone could reproduce the leak: it only happened because I was using Greasemonkey, which implements nsIContentPolicy using JavaScript. (Adblock Plus does the same, and it is apparently the most popular Firefox extension, so I'm glad this leak is fixed!)

Knowing how to debug leaks with trace-refcount logging turned out to be useful: I was able to fix a few editor leaks and debug another.

There's an interesting thread on mozilla.dev.planning about the scope and schedule of Mozilla 2.

Assertions frequently help me find bugs that would be difficult to catch otherwise. I've filed 479 bugs on assertion failures, excluding bugs that also causes crashes or hangs, and 223 of those have already been fixed. (Thanks to Brendan, I can safely file bugs when I see assertion failures, knowing that my bugs aren't invalid.)

Many assertion failures indicate that assumptions were violated in a relatively harmless way, merely causing incorrect layout or slow performance in an edge case. But sometimes they indicate the presence of a bug that could lead to a serious memory safety violation. For example, "ASSERTION: Some objects allocated with AllocateFrame were not freed" in the FrameArena destructor has helped find dozens of bugs that lead to leaks and/or dangling pointers.

Gecko developers have added many useful assertions lately, and it looks like more are on the way. Regression tests for assertions are improving, too.

I have a list of assertions that I ignore during automated testing. Whenever a developer fixes a bug on that list, I remove the bug and the corresponding assertion from the file, so if I hit the assertion again after that point, I'll notice it.

In addition to helping to catch bugs, assertions also serve as "living documentation" about the code's invariants. We notice if they become out of date, unlike Wiki pages and comments. In my dream world, assertions would also serve as waypoints for an automated theorem prover ;)

The MIT City Car page says:

The City car is NOT a replacement for personal vehicles, taxis, buses, or trucks...

It may, however, be a replacement for the Segway.