On Wed, 2011-10-05 at 18:25 +0530, Marc-André Laverdière wrote: > Hi everyone, > > Before I start writing code, I wanted to get the input of more > experienced developers. > > Why bother about this? Why not use what's available out there? Well... > - Fuzzgrind isn't well documented and won't work out of the box, > - zzuf has too many bells and whistles, and won't guarantee that every > byte has been messed up with. I used it to generate a lot of cases, and > it fills a disk quickly enough > - Peachfuzz and others that rely on a specification: well, we have file > formats with hundreds of pages specified. > > Here is the idea: > One process if the fuzzer process, it does the following (pseudocode): > > spawn "valgrind test-program" > for (i = 0; i < file.length; i++) > fuzzed = memcpy(file) > fuzzed[i] = 0xFF (or whatever) > write(temp-dir/random-name, fuzzed) > read output from the spawned process until the marker is read > if valgrind output is more than the expected valgrind start/end markers > then copy valgrind output to results directory > then copy fuzzed to results directory > if spawned program crashed then restart it > > The other process would do as follows: > while(forever) > check if a new file is in temp-dir > if the file name is "terminate-yourself", then exit > try to load the file with the filter > output a marker like "-------- Done trying to load ---------" > > With this design, we avoid a lot of process creation overhead. > We can probably generalize it enough that we can put pretty much any > filter in there. > > What do you think of this idea? What improvements we can add?
caolanm->huzaifas: any advice ? C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
