| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
Now if the input save file loads correctly, fuzzpuzz asks the back-end
to draw the puzzle. All the drawing operations are no-ops, but this
tests the drawing code in the back-end.
|
| |
|
|
|
| |
This means that the serialising code gets tested, and also provides a
convenient way to canonicalise a (valid) save file.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When reporting that the game name in a save file isn't recognised,
don't include the name from the save file in the error message, partly
to avoid the complexity of freeing it properly on two different code
paths and partly because including unsanitized data from a
fuzzer-supplied save file in the error message just seems dangerous.
And properly sanitising it would waste the fuzzer's time exploring the
sanitising code.
Thanks to Ben Hutchings for reporting the bug.
|
| | |
|
| |
|
|
| |
If deserialising a save file fails, the midend still needs to be freed.
|
| |
|
|
|
|
|
| |
Now there's a single version of the main loop that runs once in normal
mode and repeatedly in AFL++ persistent mode. In persistent mode,
fmemopen() allows the loop to read the shared-memory buffer as though
it were a stdio stream. fmemopen() is POSIX-only, but so is AFL++.
|
| |
|
|
|
|
|
| |
Rather than a save file from standard input and then exiting, this reads
it from a shared memory buffer and then loops. This makes fuzzing
_much_ faster: one core on my laptop can now load about 30,000 save
files per second.
|
|
|
This just feeds save files into the loading code, but because of how
Puzzles is structured that actually exercises most of its parsers.
|
