featurebase/roaring
Seebs 1ca9435af9 Handle file sizes over 4GB
We only have 4 bytes for offsets, but what if a file is
over 4GB? Someone came to us with a file with 265 *million* containers,
in a single fragment, which means that over 3GB of their 4.7GB file
is actually just the container headers alone. But we can't easily make
the offsets larger, or change the file format.

So we don't. We just track how many 4GB hunks of the file we've
been through and bump that every time the 32-bit offset wraps. And this
appears to... just work.

This is fixed for both the roaring iterator and the old unmarshalBinary
logic. The logic to handle this will work on 32-bit hosts in the sense
that it will correctly error out for excessively large file sizes or
container counts, but it doesn't actually handle the large files since
it can't.
2020-05-28 17:08:32 -05:00
..
testdata cleanup #1622 2018-09-06 16:27:10 -05:00
btree.go roaring: fix use-after-free in b-tree bitmap update 2020-05-20 12:01:21 -04:00
btree_test.go roaring: fix use-after-free in b-tree bitmap update 2020-05-20 12:01:21 -04:00
container_stash.go Zero bitmap storage when reusing it for container-as-bitmap 2019-11-22 16:02:42 -06:00
containers_btree.go clarify a few of the TODO comments 2020-05-19 13:50:48 -05:00
containers_slice.go The first implementation of intersect in place 2020-05-06 23:59:07 +02:00
containers_test.go The first implementation of intersect in place 2020-05-06 23:59:07 +02:00
fuzz_test.go generalize test strings and break out old UnmarshalBinary code 2019-08-05 17:39:47 -05:00
fuzzer.go added go-fuzz testing for roaring ops vs naive implementation 2019-06-25 10:47:53 -05:00
generation_debug.go Sources and Generations: tracking mmapped files 2019-11-12 12:14:29 -06:00
generation_nodebug.go Sources and Generations: tracking mmapped files 2019-11-12 12:14:29 -06:00
inst.go Add license headers to files missing them and CI check to verify they are present. Fixes #1633 2019-04-12 11:30:41 -05:00
naive.go added go-fuzz testing for roaring ops vs naive implementation 2019-06-25 10:47:53 -05:00
naive_test.go switched naive_test.go to table driven tests 2019-06-25 17:25:07 -05:00
nop_inst.go double the nolint comments, double the checking 2019-10-11 15:17:51 -05:00
README.md Fixed typo 2019-06-17 16:47:28 -05:00
roaring.go Handle file sizes over 4GB 2020-05-28 17:08:32 -05:00
roaring_helpers_test.go Make containers copy-on-write 2019-05-30 16:36:20 -05:00
roaring_internal_test.go Address TODOs in roaring tests 2020-05-21 13:28:54 -05:00
roaring_nop_paranoia.go Add license headers to files missing them and CI check to verify they are present. Fixes #1633 2019-04-12 11:30:41 -05:00
roaring_nop_sentinel.go switched naive_test.go to table driven tests 2019-06-25 17:25:07 -05:00
roaring_nop_stats.go Add license headers to files missing them and CI check to verify they are present. Fixes #1633 2019-04-12 11:30:41 -05:00
roaring_paranoia.go Add license headers to files missing them and CI check to verify they are present. Fixes #1633 2019-04-12 11:30:41 -05:00
roaring_sentinel.go switched naive_test.go to table driven tests 2019-06-25 17:25:07 -05:00
roaring_stats.go v2.0.0 2019-10-08 14:56:17 -06:00
roaring_test.go Address TODOs in roaring tests 2020-05-21 13:28:54 -05:00
source.go Sources and Generations: tracking mmapped files 2019-11-12 12:14:29 -06:00
unmarshal_binary.go Handle file sizes over 4GB 2020-05-28 17:08:32 -05:00

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!