Previous Entry Share Next Entry
Statistical bug finding was touched on in my class, but there wasn't much detail beyond Grossman saying "this is probably the future".

But apparently it's already being put to good use to find mysterious crashes in Rhythmbox:
Some of you may already be aware of the Cooperative Bug Isolation Project: <http://www.cs.berkeley.edu/~liblit/sampler/>. This is a research project at UC Berkeley and Stanford University that tries to find bugs by identifying statistically significant differences in program behavior between good and bad runs. We have a public arm, which offers instrumented binaries for popular GNOME packages for anyone to download and use. We have also been using our approach together with scripted runs to generate large numbers of feedback reports quickly.

I am pleased to report that Cooperative Bug Isolation has killed its first GNOME bug. As described in <http://bugzilla.gnome.org/show_bug.cgi?id=137460>, mining data from scripted Rhythmbox runs reveals a mismanaged timeout event source ID that can result in a fairly large number of crashes. These crashes result from memory corruption, so the post-crash stack is essentially useless. Our feedback instrumentation identifies the problem by revealing that crashes are far more likely when a specific g_source_remove() call on a specific line of code returns values greater than zero.