jepsen VS ansi-test

aphyr seems to still work on it, so probably just not that many companies who want to pay to get told the truth anymore: https://github.com/jepsen-io/jepsen

One very nice example of this is Jepsen:

https://github.com/jepsen-io/jepsen

https://github.com/jepsen-io/jepsen/issues/399

> Yeah! I mean, I find a lot of linearizability errors in various databases, but this was also my very first time doing this kind of test, and it varies from system to system. Could have easily slipped through the cracks.

In summary, aphyr thought Zookeeper is linearizable even though it doesn't provide linearizable ops.

Looks like Zookeeper needs to be tested again.

I have applied it to testing Common Lisp implementations, but there has been much work on applying it to other languages (most famously C and Javascript.)

I applied the following techniques:

(1) Generate random valid well defined programs and see (a) if they crash the compiler, (b) cause different CL implementations to produce different outputs, (c) when modified (by addition of randomly generated optimization directives or valid type declarations) they still produce the same output. This is differential testing, which was used by McKeeman at DEC in the 1990s to test C compilers, and later improved (again, on C compilers) by Yang, Chan, Eide, and Regehr at U. of Utah (csmith, creduce).

Since a running lisp image can generate and compile functions internally (this IS lisp, after all), the testing loop can be very fast. Since 2003 I have run this on and off for many billions of iterations on desktop and laptop machines on various CL implementations, now mainly on SBCL. Most of the test input reduction is handled automatically, which is a big help.

(2) Generate random possibly invalid code by mutating or recombining snippets drawn from a large corpus of code, to see if it crashes the compiler (in CL implementations where the compiler is promised to never respond to bad code by signaling an error.) This was also the approach jsfunfuzz took on Javascript.

(3) Extensive fuzzing of calls to standard functions in CL, using random generation of input values and random generation of valid type declarations, with the invariant being that the same values should be computed (and the compiler not fail.) This is a specialization of (1), but was sufficiently different that the bugs it found were not the same.

Examples of tests produced by (1) and (3) over an early period when this was being developed. Each caused a failure in some CL implementation: https://github.com/pfdietz/ansi-test/blob/master/misc/misc.l...

See also the various bugs I've reported against SBCL over the years, many of which come from this testing. https://bugs.launchpad.net/~paul-f-dietz

The experience with this sort of testing of compilers (in any language) is that if the compiler (free or commercial) has never been subjected to it, it will immediately find bugs in the compiler.