Re: [Valgrind-users] Possible bug in valgrind-1.9.4

[John R. <re...@cs...>]

> -- you've no idea how much that helps.  Reproducing problems that people
> report is the #1 problem we have in debugging V; once we reproduce a
> problem, tracking it down is simple.

Is it just reproducing the problem that's hard, or do you mean
"reproducing in a reasonable sized program"?

If the latter, then there are techniques that might be able to help.
They basically perform a space-wise or time-wise binary search in order to
narrow down the problem, exploiting the fact that we have a known-correct
implementation of an x86.

I saw a great implementation of this idea presented by Jim Gray one time.
The goal was to flush out bugs in SQL implementations.  They would
repeatedly generate these massive random queries and feed them to four or
five databases until they found a query that did not return identical
results across the databases.  They then pruned the parse tree that
generated the query until they found the smallest query that elicited
different answers from different databases, at which point the problem was
pretty obvious.

Something similar could be done with Valgrind I think.  I'm not sure that
generating random C or asm programs would work, but maybe it's possible to
turn Valgrind on and off during the execution of a program?  This would
lead to a strategy where we are searching for the briefest application of
Valgrind that gives a different result than a native x86.  Again, the
problem should be obvious at that point.

John