Index: pages/changes.in ================================================================== --- pages/changes.in +++ pages/changes.in @@ -22,10 +22,12 @@
New applications should always invoke [sqlite3_prepare_v2()] instead - of [sqlit3_prepare()]. The older [sqlite3_prepare()] is retained for + of [sqlite3_prepare()]. The older [sqlite3_prepare()] is retained for backwards compatibility. But [sqlite3_prepare_v2()] provides a much better interface.
In addition to the three major test suites, there are a few separate -programs that implement specialized tests. The "speedtest1.c" program +
In addition to the three major test harnesses, there several other +small programs that implement specialized tests. +
All of the tests above must run successfully, on multiple platforms and under multiple compile-time configurations, before each release of SQLite.
@@ -362,10 +368,40 @@The SQL fuzz generator tests are part of the TCL test suite.
During a full test run, about
The American Fuzzy Lop +or "AFL" fuzzer is a recent (circa 2014) innovation from Michal Zalewski. +Unlike most other fuzzers that blindly generate random inputs, the AFL +fuzzer instruments the program being tested (by editing the assembly-language +output from the C compiler) and uses that instrumentation to detect when +a mutated input causes the program to do something different - to follow +a new control path or loop a different number of times. Inputs that provoke +new behavior are retained and further mutated. In this way, AFL is able +to "discover" new behaviors of the program under test, including behaviors +that were never envisioned by the designers. + +
AFL has proven remarkably adept at finding arcane bugs in SQLite. +Most of the problems found have been assert() statements where the conditional +could be false under obscure circumstances. But AFL has also found +a fair number of crash bugs in SQLite, and even a few cases where SQLite +computed incorrect results. + +
Because of its past success, AFL became a standard part of the testing +strategy for SQLite beginning with [version 3.8.10]. There is at least one +instance of AFL running against SQLite continuously, 24/7/365, testing new +randomly mutated inputs against SQLite at a rate of a few hundred to a few +thousand per second. Billions of inputs have been tried, but AFL's +instrumentation has narrowed that down to less than 20,000 test cases that +cover all distinct behaviors. These distinct test cases are periodically +captured and added to the [TCL test suite] where they are rerun automatically +during routine testing.
There are numerous test cases that verify that SQLite is able to deal with malformed database files.