Background

This fix wouldn’t be in our hands if it was for the recent CrashKill effort here at Mozilla. Sam Sidler gave me a link to a list of crashes that were reported to us during a 24 hour period in SQLite and mozStorage code. I immediately started adding links to crash reports and filing bugs to some of the more frequent crashes so we could start tracking these issues. I also informed the SQLite team about this page in case they found the data useful, and they sure did. They started to look into this particular crash. It turns out that there are two other signatures that are actually the same crash, but show up differently due to compiler optimizations causing differences in the generated program.

Fix Details

SQLite has a virtual machine that processes queries. The virtual machine is register-based, which is different from the usual stack-based virtual machines you might encounter with Java. This particular crash would surface when a SQL query used an IN operator with more than ~32 thousand entries on its right-hand side and the EXISTS expression. If either of these conditions occurred on their own, SQLite could handle this just fine. The IN operator stores each entry in a register, and when processing the EXISTS expression, SQLite would store the number of the register in which an expression was written into into a 16-bit integer on an Expr object. However, once you try to write a number greater than 32,767 to a 16-bit integer, you get overflow and you will likely end up with a negative number. This negative number was then used to index into an array, which is all sorts of bad (and led to the crash).

The workaround fix is to just use a 32-bit integer for now. This means this issue will not happen unless you have over 2,147,483,647 entries on the right-hand side of the IN operator. You’d hit other limitations of SQLite before that would ever happen, so overflow is no longer a concern. The SQLite team is going to do a more complicated fix which stores the value separately from Expr object it was previously stored in. The Expr object is used a lot, so they don’t want a long-term solution that increases memory usage.

You might be surprised that such a small and trivial seeming bug got through. This type of bug is more common than you might think, and overflow bugs have even caused the destruction of an Ariane 5 rocket. It’s an unfortunate reality of software that sometimes these edge cases get missed, but we must always try to remain vigilant.

Special thanks to the SQLite team for investigating this fix, and providing information for this blog post.
Provide anonymous feedback on this post with Rypple.

Background

We’ve been getting reports for some time about the location bar hanging the application for some users when they are typing in it. This wasn’t a problem that was reproducible on every machine, and even on machines that saw it, it wasn’t always 100% reproducible. Clearly, this behavior is not desirable, so we set out to fix it.

I had a theory to the cause almost a year ago and filed a bug that I was hoping we could work on and fix for Firefox 3.5. We knew that reading data off a disk can be slow (and certainly would complete in a non-deterministic amount of time). Since SQLite uses blocking read calls (no more code can execute until the data is read from disk), this could certainly be the cause of the slowdown our users were seeing. Some simple profiling showed that this was largely the cause of the hanging. Work began on the project, but it was clear that enough issues were cropping up that we were not going to be able to safely take this change for Firefox 3.5, and resources were diverted elsewhere.

Process and Solution

This section is a bit technical, so feel free to skip it. The short answer is “do not block the main thread while reading from the hard drive.”

In order to not block the main thread while reading from disk we either need to make SQLite use non-blocking read system calls, or call into SQLite off of the main thread. Changing the SQLite code isn’t something we want to do, so that solution was out of the question. Luckily, we had solved a similar problem with writes and fsyncs earlier in the Firefox 3.5 development with the asynchronous Storage API.

The first implementation that we tried essentially did the same thing that the old code did. We would execute a query, but this time asynchronously, and then process the results and see if they match. There were two issues with this approach, however. The first issue was that we were filtering every history and bookmark entry on the main thread for a given search. That could be a lot of work we end up doing, and with the additional overhead of moving data across threads, the common case would see no win. The second issue was that once we selected a result in the location bar, and a search was not yet complete, there would be a hang as the main thread processed a bunch of events that Storage had posted to it containing results.

At this point, we realized we needed to do the filtering on a thread other than the main thread. After some thought, we was figured that the easiest way to do that would be to use a SQL function that we define in the WHERE clause of our autocomplete queries. This way, all the filtering is done on a background thread, and the code that runs on the main thread only deals with results we will actually use. This solution exposed some things in the Storage backend like lock contention and a few other subtle issues, but nothing major came up.

For more details on how the location bar search results are generated, see my explanation here.

If you weren’t having a problem before, chances are you won’t notice any difference at all.

With my work on the asynchronous location bar, I wanted to speed up the call to executeAsync to make it as fast as possible so autocomplete look ups would be quick. To accomplish this, we now cache the asynchronous sqlite3_stmt object so we don’t recreate it on every call to executeAsync. This amortizes the cost that was causing the asynchronous API to be slower than the synchronous one.

This solution is not sufficient, however, if you bind parameters to the statement before calling executeAsync. This is because binding parameters stores state on the underlying sqlite3_stmt object, and we can’t store that information on it because it could be in use on the background thread. To get around this issue, I reuse a code from the recent asynchronous storage API addition to store the bound values in memory and then bind them at the time of execution on the background thread. Andrew Sutherland and I were both very happy at how small this patched ended up being as a result of good API design in the past.

The bonus with this two step solution is that we’ve also completely removed the possibility of lock contention inside of the SQLite library on the calling thread of executeAsync. If you have a long running sqlite3_step command on the background thread, this could block your call to one of the binding calls or executeAsync, which is undesirable.

This code is checked in on mozilla-central, and will be a part of Gecko 1.9.2.

// Note: db is the mozIStorageConnection for our database.
var stmt = db.createStatement("INSERT INTO table_name (table_value)" +
                              "VALUES (:value)");
var values = [
  "val1",
  "val2",
  "val3",
];
var array = stmt.newBindingParamsArray();
for (let i = 0; i < values.length; i++) {
  let params = array.newBindingParams();
  params.bindByName("value", values[i]);
  array.addParams(params);
}
stmt.bindParameters(array);
stmt.executeAsync(); // This will insert all the values into the table.

It's not the prettiest thing in the wold, and I hope to add some language helpers for JavaScript to make this even easier to use from JavaScript. Hope you find it useful!

For those of your programmers out there, I have a word of advice. Always make sure you have a virtual destructor in your base class. If you don’t, you could spend days tracking down a leak that doesn’t seem to make sense. Of course, this probably would have been spotted earlier if we reported leaks in xpcshell unit tests.

Luckily, SQLite exposes a handy function that tells us this information. In general, you want to use a index in your ORDER BY clause so SQLite can use it to generate the order the results a given back. If you do not use an index, SQLite has to first get all the results in memory, then it sorts them, and then it starts to return results. If you expect a lot of results, this can get very expensive.

There were suggestions on the newsgroups to also add an API so debuggers such as ChromeBug or SQLite Manager could listen for these types of errors. I’ll be filing follow-up bugs for some of these suggestions later on.