ceaf5c15d1
This is logically two separate things, but the individual changes are thoroughly intertwined in the code. The first change is a logical change to the design of the snapshot queue, which is that it now adjusts the maxOpN the background scan targets, allowing it to lower that value over time when things are quiet. We do this because it turns out that on large data sets, this can make a factor-of-four difference in memory usage! So, in general, on a quiet system, each pass through the holder aims for about 1/4 of the existing fragments to get snapshotted. When there's more load, we adjust those values up. We also make the snapshot queue a bit less chatty, to make testing less annoying -- we only print stats if the queue enqueues at least two snapshots, or skips any. The second change is threading the holder through things. We've always threaded the logger through, and then added the snapshot queue, and some of the Inspect-related work led to wanting to have a way to thread options through, so what if we just threaded the holder itself through, and removed the direct copying around of the logger, snapshot queue, and so on. Similarly, everything can now use holder.PartitionN instead of having to get its own copy of PartitionN handed out to each index. This does imply ensuring that test cases always get a reasonable default holder. This is a precursor to adding additional information to the holder, such as whether it's in a special read-only mode, which would imply not modifying on-disk files. This is already semi-supported for the specific case of the background snapshot queue and cache flushing, which are attached to the (created in a previous commit) new holder Activate method, instead of being automatic on holder Open. The change to a snapshot queue can also cause races in tests, because the fragment.Clean method's "sanity check" accesses a fragment without a lock. Fix that. Since there's a couple of t.Fatalf(), but we need to release the lock before closing, we use an anonymous function with a defer to handle that. Whee! |
||
|---|---|---|
| .. | ||
| testdata | ||
| btree.go | ||
| btree_test.go | ||
| container_stash.go | ||
| containers_btree.go | ||
| containers_slice.go | ||
| containers_test.go | ||
| fuzz_test.go | ||
| fuzzer.go | ||
| generation_debug.go | ||
| generation_nodebug.go | ||
| inst.go | ||
| naive.go | ||
| naive_test.go | ||
| nop_inst.go | ||
| README.md | ||
| roaring.go | ||
| roaring_helpers_test.go | ||
| roaring_internal_test.go | ||
| roaring_nop_paranoia.go | ||
| roaring_nop_sentinel.go | ||
| roaring_nop_stats.go | ||
| roaring_paranoia.go | ||
| roaring_sentinel.go | ||
| roaring_stats.go | ||
| roaring_test.go | ||
| source.go | ||
| unmarshal_binary.go | ||
The Fuzzer
For complete documentation on go-fuzz, please see: https://github.com/dvyukov/go-fuzz
The fuzzer in relation to the roaring package checks the Bitmap.UnmarshalBinary function found in roaring.go. In order to use the fuzzer, you can follow these steps:
cd $GOPATH/src/github.com/pilosa/pilosa/roaring
go-fuzz-build ./
You must now make the workdir/corpus directory. This is achieved by:
mkdir workdir/corpus
The fuzzer needs some input to start the fuzzing with. Copy some sample Pilosa fragments into the workdir/corpus folder. For example:
cp ~/.pilosa/my-index/my-field/views/standard/fragments/0 workdir/corpus
Once you have copied your sample inputs, you are ready to run the fuzzer:
go-fuzz -bin=roaring-fuzz.zip -workdir=workdir -func=FuzzBitmapUnmarshalBinary
Understanding the Fuzzer Output
The fuzzer will output something similar to the follwoing:
2015/04/25 12:39:53 workers: 8, corpus: 124 (12s ago), crashers: 37, restarts: 1/15, execs: 35342 (2941/sec), cover: 403, uptime: 12s
The most important part of the output is the crashers and cover. The crashers records how many combinations were discovered that fail and the cover tells you how much code is being accessed.
For a complete explanation of the output, please see: https://github.com/dvyukov/go-fuzz.
The fuzzer will document the crashers in a folder labeled "crashers." It will record the fragment and the error that was produced in two separate files within this folder. This is the final product.
Happy Fuzzing!